I worked at Microsoft during the development of this - and I'm so very happy it finally shipped.
We started working on this about a year ago after chatting with npm, git, Ember, and various other command line tools that were substantially slower (or straight up broken) on Windows. I casually mentioned how big of a performance impact we could have to Satya's Assistant and found myself in a meeting with all required groups (filesystems, security, etc), making my case for non-elevated symlink support, within a few days.
Windows still is a massive tanker, but I'm so excited for the Microsoft that is able to make sensible changes quickly.
Can you (or anyone else) explain the rationale behind having to specify a new flag SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE? What's wrong with simply just not removing SeCreateSymboliclinkPrivilege from the restricted token, and by default including it from unprivileged users?
The primary motivation for adding the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag is to not disrupt the behavior of existing code.
Because of pre-existing behavior, existing apps are likely to be built to assume that symlinks cannot be created when the app is running without admin rights. If the behavior changed such that the app could now create symlinks but not have admin rights, the app and/or its dependent scripts etc. will likely misbehave.
Therefore, we added a new flag - SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE - which allows developers to expressly indicate that their code is specifically built to handle the ability to create symlinks should their code be running on a supporting platform (i.e. Win10 Creators Update, or later) even if the app does not have admin rights.
Sounds unlikely given that you could already give SeCreateSymbolicLink to any users - and the thought that someone could rely on a privilege not being there in the restricted token sounds pretty terrifying to me.
Fantastic work :) It's always worth bringing up stuff like this. In the open source world, I find just asking for features has about a 1 in 10 success rate so always worth it.
Hopefully there will be a way of editing these in explorer too at some point.
Thanks a lot for making this. I found out about this while installing Git 2.11 when it asked if I'd like to enable symlink support. Makes life a lot easier.
We started working on this about a year ago after chatting with npm, git, Ember, and various other command line tools that were substantially slower (or straight up broken) on Windows. I casually mentioned how big of a performance impact we could have to Satya's Assistant and found myself in a meeting with all required groups (filesystems, security, etc), making my case for non-elevated symlink support, within a few days.
Windows still is a massive tanker, but I'm so excited for the Microsoft that is able to make sensible changes quickly.