Re: Using native symlinks
On May 30 09:28, Jeffrey Altman wrote: On 5/30/2013 5:03 AM, Corinna Vinschen wrote: On the other hand, in the same situation the UAC-crippled admins's token does not contain the Create symbolic links right: $ /cygdrive/c/Windows/System32/whoami /priv PRIVILEGES INFORMATION -- Privilege NameDescription State = SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled I also changed the Create symbolic links policy so that the Users group is the only group getting this right. In other words, I removed the Administrators group entirely, logged off, logged on, and the result was the same as above. This is a bug in UAC if you ask me. It seems to remove privileges from the UAC-crippled admin's token based on a fixed internal list, totally ignorant of changes in the security policy. This is a design flaw but it is working as documented. Administrators have SeCreateSymbolicLinkPrivilege by default so UAC removes it. What UAC should do in my opinion is not remove a static list of permissions but only remove those permissions that are not granted to standard users. ACK. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On May 29 20:43, Chris Sutcliffe wrote: On 29 May 2013 13:01, Corinna Vinschen wrote: On May 29 12:40, Chris Sutcliffe wrote: On 29 May 2013 11:23, Corinna Vinschen wrote: On May 29 10:33, Chris Sutcliffe wrote: On 29 May 2013 04:39, Corinna Vinschen wrote: Also, either way, did you logoff and logon so that the Create symbolic links user right can be added to your user token? Note that your token remains unchanged if you didn't exit from your session. Just changing the Policy isn't enough, the OS needs achance to create a new user token for you containing the user right. I've rebooted the machine since making the change and it has had no affect. Is there something else I need to do? I don't know. I have to try (but not today). Did you try to add the Users group to the Local Security Policy entry instead? I tried adding the Users group and it didn't help either. I just tested it and can confirm it. Try this: Start a login session of a normal user after adding the Users group to the Create symbolic links right. Check the privileges in the user token: $ /cygdrive/c/Windows/System32/whoami /priv PRIVILEGES INFORMATION -- Privilege NameDescription State = SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled SeCreateSymbolicLinkPrivilege Create symbolic linksDisabled On the other hand, in the same situation the UAC-crippled admins's token does not contain the Create symbolic links right: $ /cygdrive/c/Windows/System32/whoami /priv PRIVILEGES INFORMATION -- Privilege NameDescription State = SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled I also changed the Create symbolic links policy so that the Users group is the only group getting this right. In other words, I removed the Administrators group entirely, logged off, logged on, and the result was the same as above. This is a bug in UAC if you ask me. It seems to remove privileges from the UAC-crippled admin's token based on a fixed internal list, totally ignorant of changes in the security policy. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On 5/30/2013 5:03 AM, Corinna Vinschen wrote: On the other hand, in the same situation the UAC-crippled admins's token does not contain the Create symbolic links right: $ /cygdrive/c/Windows/System32/whoami /priv PRIVILEGES INFORMATION -- Privilege NameDescription State = SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled I also changed the Create symbolic links policy so that the Users group is the only group getting this right. In other words, I removed the Administrators group entirely, logged off, logged on, and the result was the same as above. This is a bug in UAC if you ask me. It seems to remove privileges from the UAC-crippled admin's token based on a fixed internal list, totally ignorant of changes in the security policy. This is a design flaw but it is working as documented. Administrators have SeCreateSymbolicLinkPrivilege by default so UAC removes it. What UAC should do in my opinion is not remove a static list of permissions but only remove those permissions that are not granted to standard users. If your organization is a user of native symlinks and you have a support agreement with Microsoft, I recommend filing a support request to have this behavior changed. Jeffrey Altman -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On May 28 22:23, Chris Sutcliffe wrote: On 28 May 2013 14:55, Corinna Vinschen wrote: On May 28 14:16, Chris Sutcliffe wrote: What permissions do I need for native symlinks to work? According to edit rights I have SeCreateSymbolicLinkPrivilege (when checking via an elevated shell - i.e. with Run as Administrator): ┌─┤ csutclif@bmotec3017201lt ├──┤ ~ │ └─┤ 14:11 ├─ editrights -u $USER -l SeLockMemoryPrivilege SeCreateSymbolicLinkPrivilege However, if I try and create a native symlink it still fails. If using the winsymlink:native option I get a cygwin symlink, winln That's winsymlinks:native I hope... Correct, I mistyped. pops up a message stating I need the SeCreateSymbolicLinkPrivilege. Not sure if it's relevant or not, but the $USER in this case is a domain user, not a local user. Are you sure it's an elevated shell? `id -G' should contain 544. Is the filesystem NTFS? Is it a local NTFS or a remote NTFS hosted by a Vista-or-later OS? If you set CYGWIN=winsymlink It works fine if I create the native symlinks in an elevated shell, but does not if I create the native symlinks in a normal shell. Is this expected (i.e. does creating native symlinks only work in elevated shells?). Welcome to the wonderful world of native NTFS symlinks!!1!11!! It's true and it works like this: Have a look into the Local Security Policy MMC Snap-in. In the left hand tree view navigate to Security Settings - Local Policies - User Rights Assignments. On the right side look for Create symbolic links. You will see that by default only members of the Administrators group are allowed to create symlinks. If you're running under an admin account in a non-elevated shell, your token has been stripped by all Admin-only user rights, so you also have no right to create symlinks. To workaround that, you can either add yourself to the Create symbolic links right, or you can add the Users group if you want to allow every user to create symlinks. But this requires changing it on all machines manually, so alternatively you can create a domain policy which adds the trusted users to this user right on all machines. As if that isn't bad enough, there's another ugly surprise for the uninitiated: In an elevated shell, call fsutil like this: $ fsutil behavior query SymlinkEvaluation Local to local symbolic links are enabled. Local to remote symbolic links are enabled. Remote to local symbolic links are disabled. Remote to remote symbolic links are disabled. See the word disabled for remote-local and remote-remote symlinks? This means, by default the system will suppress the evaluation of remote symlinks which point to a local filesystem, as well as the evaluation of remote symlinks which point to a remote location. In CMD you'd see an error The symbolic link cannot be followed because its type is disabled aka STATUS_SYMLINK_CLASS_DISABLED. On Windows 8, this even goes as far as affecting NFS symlinks! If you have a symlink to a directory, with symlinks underneath, resolving the second level of symlinks fails with STATUS_NETWORK_OPEN_RESTRICTION if remote-remote symlinks are disabled in fsutil. Funny, right? The workaround is `fsutil behavior set r2l:1 r2r:1'. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On 29 May 2013 04:39, Corinna Vinschen wrote: On May 28 22:23, Chris Sutcliffe wrote: It works fine if I create the native symlinks in an elevated shell, but does not if I create the native symlinks in a normal shell. Is this expected (i.e. does creating native symlinks only work in elevated shells?). Welcome to the wonderful world of native NTFS symlinks!!1!11!! It's true and it works like this: Have a look into the Local Security Policy MMC Snap-in. In the left hand tree view navigate to Security Settings - Local Policies - User Rights Assignments. On the right side look for Create symbolic links. You will see that by default only members of the Administrators group are allowed to create symlinks. If you're running under an admin account in a non-elevated shell, your token has been stripped by all Admin-only user rights, so you also have no right to create symlinks. To workaround that, you can either add yourself to the Create symbolic links right, or you can add the Users group if you want to allow every user to create symlinks. But this requires changing it on all machines manually, so alternatively you can create a domain policy which adds the trusted users to this user right on all machines. I tried this approach and I'm still not having any luck with the user being able to create native symbolic links in a non-elevated shell. As a work around I've created a 'sudo' alias: alias sudo='cygstart --action=runas' which works nicely as I can launch commands elevated from a non-elevated shell. For running commands like winln / ln I can add the --hidden option (i.e. sudo --hidden) and no cmd window will pop-up during the execution of the command. I figured I would pass this along in case someone else finds this useful. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On May 29 10:33, Chris Sutcliffe wrote: On 29 May 2013 04:39, Corinna Vinschen wrote: On May 28 22:23, Chris Sutcliffe wrote: It works fine if I create the native symlinks in an elevated shell, but does not if I create the native symlinks in a normal shell. Is this expected (i.e. does creating native symlinks only work in elevated shells?). Welcome to the wonderful world of native NTFS symlinks!!1!11!! It's true and it works like this: Have a look into the Local Security Policy MMC Snap-in. In the left hand tree view navigate to Security Settings - Local Policies - User Rights Assignments. On the right side look for Create symbolic links. You will see that by default only members of the Administrators group are allowed to create symlinks. If you're running under an admin account in a non-elevated shell, your token has been stripped by all Admin-only user rights, so you also have no right to create symlinks. To workaround that, you can either add yourself to the Create symbolic links right, or you can add the Users group if you want to allow every user to create symlinks. But this requires changing it on all machines manually, so alternatively you can create a domain policy which adds the trusted users to this user right on all machines. I tried this approach and I'm still not having any luck with the user being able to create native symbolic links in a non-elevated shell. What approach? Adding the Users group to the Local Security Policy or adding a domain policy? If the latter, did you call gpupdate on the client or reboot the client machine to propagate the domain policy? Also, either way, did you logoff and logon so that the Create symbolic links user right can be added to your user token? Note that your token remains unchanged if you didn't exit from your session. Just changing the Policy isn't enough, the OS needs achance to create a new user token for you containing the user right. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On 29 May 2013 11:23, Corinna Vinschen wrote: On May 29 10:33, Chris Sutcliffe wrote: On 29 May 2013 04:39, Corinna Vinschen wrote: To workaround that, you can either add yourself to the Create symbolic links right, or you can add the Users group if you want to allow every user to create symlinks. But this requires changing it on all machines manually, so alternatively you can create a domain policy which adds the trusted users to this user right on all machines. I tried this approach and I'm still not having any luck with the user being able to create native symbolic links in a non-elevated shell. What approach? Adding the Users group to the Local Security Policy or adding a domain policy? If the latter, did you call gpupdate on the client or reboot the client machine to propagate the domain policy? I've added the specific domain user in the Local Security Policy as I am not a domain admin (only an admin on the local machine) and as such cannot propagate a domain policy change. Also, either way, did you logoff and logon so that the Create symbolic links user right can be added to your user token? Note that your token remains unchanged if you didn't exit from your session. Just changing the Policy isn't enough, the OS needs achance to create a new user token for you containing the user right. I've rebooted the machine since making the change and it has had no affect. Is there something else I need to do? Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On May 29 12:40, Chris Sutcliffe wrote: On 29 May 2013 11:23, Corinna Vinschen wrote: On May 29 10:33, Chris Sutcliffe wrote: On 29 May 2013 04:39, Corinna Vinschen wrote: To workaround that, you can either add yourself to the Create symbolic links right, or you can add the Users group if you want to allow every user to create symlinks. But this requires changing it on all machines manually, so alternatively you can create a domain policy which adds the trusted users to this user right on all machines. I tried this approach and I'm still not having any luck with the user being able to create native symbolic links in a non-elevated shell. What approach? Adding the Users group to the Local Security Policy or adding a domain policy? If the latter, did you call gpupdate on the client or reboot the client machine to propagate the domain policy? I've added the specific domain user in the Local Security Policy as I am not a domain admin (only an admin on the local machine) and as such cannot propagate a domain policy change. Also, either way, did you logoff and logon so that the Create symbolic links user right can be added to your user token? Note that your token remains unchanged if you didn't exit from your session. Just changing the Policy isn't enough, the OS needs achance to create a new user token for you containing the user right. I've rebooted the machine since making the change and it has had no affect. Is there something else I need to do? I don't know. I have to try (but not today). Did you try to add the Users group to the Local Security Policy entry instead? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On 29 May 2013 13:01, Corinna Vinschen wrote: On May 29 12:40, Chris Sutcliffe wrote: On 29 May 2013 11:23, Corinna Vinschen wrote: On May 29 10:33, Chris Sutcliffe wrote: On 29 May 2013 04:39, Corinna Vinschen wrote: Also, either way, did you logoff and logon so that the Create symbolic links user right can be added to your user token? Note that your token remains unchanged if you didn't exit from your session. Just changing the Policy isn't enough, the OS needs achance to create a new user token for you containing the user right. I've rebooted the machine since making the change and it has had no affect. Is there something else I need to do? I don't know. I have to try (but not today). Did you try to add the Users group to the Local Security Policy entry instead? I tried adding the Users group and it didn't help either. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Using native symlinks
What permissions do I need for native symlinks to work? According to edit rights I have SeCreateSymbolicLinkPrivilege (when checking via an elevated shell - i.e. with Run as Administrator): ┌─┤ csutclif@bmotec3017201lt ├──┤ ~ │ └─┤ 14:11 ├─ editrights -u $USER -l SeLockMemoryPrivilege SeCreateSymbolicLinkPrivilege However, if I try and create a native symlink it still fails. If using the winsymlink:native option I get a cygwin symlink, winln pops up a message stating I need the SeCreateSymbolicLinkPrivilege. Not sure if it's relevant or not, but the $USER in this case is a domain user, not a local user. Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On May 28 14:16, Chris Sutcliffe wrote: What permissions do I need for native symlinks to work? According to edit rights I have SeCreateSymbolicLinkPrivilege (when checking via an elevated shell - i.e. with Run as Administrator): ┌─┤ csutclif@bmotec3017201lt ├──┤ ~ │ └─┤ 14:11 ├─ editrights -u $USER -l SeLockMemoryPrivilege SeCreateSymbolicLinkPrivilege However, if I try and create a native symlink it still fails. If using the winsymlink:native option I get a cygwin symlink, winln That's winsymlinks:native I hope... pops up a message stating I need the SeCreateSymbolicLinkPrivilege. Not sure if it's relevant or not, but the $USER in this case is a domain user, not a local user. Are you sure it's an elevated shell? `id -G' should contain 544. Is the filesystem NTFS? Is it a local NTFS or a remote NTFS hosted by a Vista-or-later OS? If you set CYGWIN=winsymlink Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using native symlinks
On 28 May 2013 14:55, Corinna Vinschen wrote: On May 28 14:16, Chris Sutcliffe wrote: What permissions do I need for native symlinks to work? According to edit rights I have SeCreateSymbolicLinkPrivilege (when checking via an elevated shell - i.e. with Run as Administrator): ┌─┤ csutclif@bmotec3017201lt ├──┤ ~ │ └─┤ 14:11 ├─ editrights -u $USER -l SeLockMemoryPrivilege SeCreateSymbolicLinkPrivilege However, if I try and create a native symlink it still fails. If using the winsymlink:native option I get a cygwin symlink, winln That's winsymlinks:native I hope... Correct, I mistyped. pops up a message stating I need the SeCreateSymbolicLinkPrivilege. Not sure if it's relevant or not, but the $USER in this case is a domain user, not a local user. Are you sure it's an elevated shell? `id -G' should contain 544. Is the filesystem NTFS? Is it a local NTFS or a remote NTFS hosted by a Vista-or-later OS? If you set CYGWIN=winsymlink It works fine if I create the native symlinks in an elevated shell, but does not if I create the native symlinks in a normal shell. Is this expected (i.e. does creating native symlinks only work in elevated shells?). In this case the Domain user is a member of the local administrators group on the local machine. This filesystem is a local NTFS hosted on Windows 7. Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
