Using native symlinks

Using native symlinks

[Chris Sutcliffe]

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

[Corinna Vinschen]

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

[Chris Sutcliffe]

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

Re: Using native symlinks

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Chris Sutcliffe]

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

[Chris Sutcliffe]

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

[Corinna Vinschen]

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

[Chris Sutcliffe]

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

Re: Using native symlinks

[Corinna Vinschen]

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 Name                Description                          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 links                Disabled

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 Name                Description                          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

[Jeffrey Altman]

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 Name                Description                          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

[Corinna Vinschen]

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 Name                Description                          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