DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:content-transfer-encoding
	:in-reply-to; q=dns; s=default; b=IpzpUEqXfBOwmVJMiSltLJ5TxpCLGy
	p7VAviXi0oJziiCrXW0xhOxY4tlIEXS9zFsVg3O/n/EadYdlhCHdPl5f3CmlZaGI
	0tdfr4FZGj72YyhBVg5wp4XMTd0LoFObBMMPQgh5rOPBkPVsQPTt2gBXP1yvyUJX
	3R0z7xr7D2juc=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Wed, 29 May 2013 10:39:10 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Using native symlinks
Message-ID: <20130529083910.GD31309@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <CAGHJv4ftSKS6wR-Uzd9Gfvowqpn-WCQ0U01NexgCpZaYqd-Tow@mail.gmail.com> <20130528185553.GA31309@calimero.vinschen.de> <CAGHJv4fkvRt1gQfNTarHGUQWvdRxRsy=oAA=pjUQTLQFoNoW-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAGHJv4fkvRt1gQfNTarHGUQWvdRxRsy=oAA=pjUQTLQFoNoW-g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Note-from-DJ: This may be spam

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