-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add non-elevated symlink support for dev mode Windows 10 #75693
Comments
As explained in this Microsoft blogpost (https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/), it is possible on newer versions of Windows 10 for non-privileged users to create symlinks when the machine is in developer mode. However, to ensure backwards compatibility, this behavior requires a flag to be passed to the CreateSymbolicLink function. I think this is something that Python can benefit from having. It would go from "symlinks on Windows rarely work" to "symlinks on Windows work in developer mode (and rarely otherwise)". I've attached a proof of concept patch to enable this behavior (a Windows 10 machine with the 'Creators Update' is required to test it). In summary, it enables the flag by default, and updates enable_symlink to prevent lacking privilege from disabling symlinks on machines in developer mode. |
Py_CreateSymbolicLinkW can be removed in 3.5+ because Windows XP is no longer supported and calling enable_symlink() is pointless. The Windows API uses some privileges simply to determine which security principals can access a capability. Whether the privilege is currently enabled or disabled in the current access token doesn't matter because functions automatically enable it for the current thread (in an impersonation token). In this case, CreateSymbolicLink calls RtlAcquirePrivilege to enable SeCreateSymbolicLinkPrivilege for the current thread; sets the symlink reparse point; and then reverts the current thread via RtlReleasePrivilege. It goes through these same steps whether or not the privilege is already enabled in the process, so there's no chance of a race condition between competing threads. Also, as a side note, the linked blog makes the following claim, which paints an incomplete picture:
SeCreateSymbolicLinkPrivilege can be added to a standard user account, and it doesn't get filtered out from the user's token. So in general you do not need administrator access. However, the above is describing the case for most developers, who use a administrator account that's subject to UAC restrictions. |
Thanks for the informative comments. I opened a PR based on this feedback. Would you mind checking if it conforms to what you had in mind? |
The PR has been sitting for a while now with all previous concerns addressed. There has been a few pings on the PR without anything new happening, so I thought I would ping this issue as well: are there any other concerns about this PR, or anything else that is preventing it from being merged? |
Thanks for the ping (I don't see GitHub notifications - I get 1000s per day and it's not feasible to read them). I left one more comment on the PR, but then it's good to go! |
Thanks! I addressed the comment, so hopefully this should be OK now. |
:ping: It seems this was ready to be merged a while ago. |
Done |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: