Re: Using cp converts windows junctions to a cywin symlink; a security-config override

[Linda Walsh <cygwin@tlinx.org>]

Andrey Repin wrote:
Greetings, Adrian H!

> > I was copying a directory of files, some of which were windows junctions.
> > These got converted to a cygwin symlink.  Although I am impressed that there
> > are such a thing for those OSs/drives that do not support such things, for those
> > that do, I think it would be good to keep the copy a junction.  Otherwise,
> > things can get messy.

> > Can this be corrected?
---

(BTW -- you do know about the 'winsymlinks:native' setting in the
CYGWIN environment variable?  It might be of some use.)

Andrey wrote:
> Unfortunately, even on systems, that do support symlinks functionality,
> it is restricted by UAC and not easily unlocked.
--- 
Actually that's control by Windows group policy.

It's alot like whether not 'users' can control 'mounts' on linux.
It can be allowed, but doing so categorically might not be considered
wise.

> You'd need an admin shell or a user profile with UAC turned off and
> permissions correctly configured to exploit native symlinks.
--- 
Or the system administrator would have to enable user-control of local
symlinks.

The ability to allow users to create and use symlinks is control through
4 settings:

> fsutil behavior query SymlinkEvaluation
* Local to local symbolic links are enabled.  
* Local to remote symbolic links are enabled.  
* Remote to local symbolic links are enabled.  
* Remote to remote symbolic links are enabled.

--- 

On my windows machine, unprivileged users are able to create all 4 types
of symbolic links.

As for junctions and mountvols -- they require the same privileges on
windows as they do on linux.

I.e. a normal user can't mount or graft portions of the file system other
places -- mount is normally restricted to root-only.  Having cygwin
destroy/overwrite linux-comparable 'mounts' would be and should be
considered a serious security bug.

If I mount a linux dir at another location -- imagine if 'cp' changed
those mount point to symbolic links (which no longer work consistently or
the same on linux as they use to, as some security-spazes came up with the
idea that being able to create a symlink (not hardlink) to a file you
don't own, was considered a security risk -- even though in reality
symlinks are safer than hardlinks in such cases, because the symlinks have
to traverse the intervening directories and security checks.  On windows,
the "allow traversing paths you don't have access to" is a privilege that
has been used to allow users access to area they didn't normally have
access to.  However, on linux there never was such a privilege, so the
added the ability to mount normally "private" areas in other places --
going around the intermediate path-walk-security checks.  

Now with the mount option, the default on most distros is to disable
creating symlinks to files you don't own -- which doesn't serve the same
purpose -- since such symlinks STILL follow all the intervening security
checks at each directory.

Note--disabling the windows privilege to bypass traversed directory
security checks would achieve the same effect on windows as it does on
linux, but MS strongly advises against doing this, as so much software
makes use of this feature and assumes it is in place (it is the default).

To find out more about the linux google on
/proc/sys/fs/protected_hardlinks & /proc/sys/fs/protected_symlinks

> And Cygwin does not support creation of directory junctions to the best
> of my knowledge. :(
---
	Neither does linux support creation of user-controlled mounts.

	
Not have cygwin destroy "volume mount points" that are
a parallel to linux's ability to mount any directory anywhere else, would
be very useful. Destroying the mountpoints as it does now, is
a hacker's dream, as they can destroy a local admin's mounting
of a read-only dir there and allow potentially virus laden programs
to replace them.

Nice.

 


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