This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients eryksun, paul.moore, steve.dower, tim.golden, vidartf, zach.ware
Date 2017-09-19.00:35:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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:

> However, for Windows users, due to Windows Vista’s security 
> requirements, users needed local admin rights and, importantly, 
> had to run mklink in a command-line console elevated as 
> administrator to create/modify symlinks. 

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.
Date User Action Args
2017-09-19 00:35:32eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, vidartf
2017-09-19 00:35:32eryksunsetmessageid: <>
2017-09-19 00:35:32eryksunlinkissue31512 messages
2017-09-19 00:35:30eryksuncreate