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.
