public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Using cp converts windows junctions to a cywin symlink
@ 2015-11-02 18:57 Adrian H
  2015-11-02 20:05 ` Andrey Repin
  2015-11-03 13:20 ` Using cp converts windows junctions to a cywin symlink Corinna Vinschen
  0 siblings, 2 replies; 5+ messages in thread
From: Adrian H @ 2015-11-02 18:57 UTC (permalink / raw)
  To: cygwin

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?

Thanks,


A

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using cp converts windows junctions to a cywin symlink
  2015-11-02 18:57 Using cp converts windows junctions to a cywin symlink Adrian H
@ 2015-11-02 20:05 ` Andrey Repin
  2015-11-02 23:32   ` Using cp converts windows junctions to a cywin symlink; a security-config override Linda Walsh
  2015-11-03 13:20 ` Using cp converts windows junctions to a cywin symlink Corinna Vinschen
  1 sibling, 1 reply; 5+ messages in thread
From: Andrey Repin @ 2015-11-02 20:05 UTC (permalink / raw)
  To: Adrian H, cygwin

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?

Unfortunately, even on systems, that do support symlinks functionality, it is
restricted by UAC and not easily unlocked.
You'd need an admin shell or a user profile with UAC turned off and permissions
correctly configured to exploit native symlinks.
And Cygwin does not support creation of directory junctions to the best of my
knowledge. :(


-- 
With best regards,
Andrey Repin
Monday, November 2, 2015 22:48:43

Sorry for my terrible english...


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using cp converts windows junctions to a cywin symlink; a security-config override
  2015-11-02 20:05 ` Andrey Repin
@ 2015-11-02 23:32   ` Linda Walsh
  2015-11-02 23:50     ` Andrey Repin
  0 siblings, 1 reply; 5+ messages in thread
From: Linda Walsh @ 2015-11-02 23:32 UTC (permalink / raw)
  To: cygwin, adrianh.bsc, anrdaemon

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using cp converts windows junctions to a cywin symlink; a security-config override
  2015-11-02 23:32   ` Using cp converts windows junctions to a cywin symlink; a security-config override Linda Walsh
@ 2015-11-02 23:50     ` Andrey Repin
  0 siblings, 0 replies; 5+ messages in thread
From: Andrey Repin @ 2015-11-02 23:50 UTC (permalink / raw)
  To: Linda Walsh, cygwin

Greetings, Linda Walsh!

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

Yes, I know. But when UAC is enabled, it overriding this policy setting.
That's why I said that you need either admin console, or UAC turned off.

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

Microsoft does not follow common logic.

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

...

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

Do you have UAC enabled?

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

However, Windows allows creation of directory junctions just fine.
But blocks Symlinks.


-- 
With best regards,
Andrey Repin
Tuesday, November 3, 2015 02:34:22

Sorry for my terrible english...


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Using cp converts windows junctions to a cywin symlink
  2015-11-02 18:57 Using cp converts windows junctions to a cywin symlink Adrian H
  2015-11-02 20:05 ` Andrey Repin
@ 2015-11-03 13:20 ` Corinna Vinschen
  1 sibling, 0 replies; 5+ messages in thread
From: Corinna Vinschen @ 2015-11-03 13:20 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

On Nov  2 13:57, Adrian H wrote:
> 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?

No.  The actual copy is done by the application, not by Cygwin.  The
application (cp, rsync, whatnot) is a POSIX application which has no
notion of "junctions".  From the view of the POSIX application,
directory junctions are symlinks.  So the copying application will call
the symlink or symlinkat function.  This call has no idea that the
to-be-created symlink is a copy of a directory juntion.  After all,
there 's no connection between the stat call on the source and the
symlink call on the destination.

To alleviate this partially, you can copy with the environment variable
CYGWIN set to "winsymlinks:native" or "winsymlinks:nativestrict".  This
will create native symlinks, not directory junctions, so it requires the
"Create symbolic links" privilege set for the current user, but it's
better than nothing.  From a consumer perspective, a directory junction
and a symlink to a directory are not really different.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-11-03 13:20 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-02 18:57 Using cp converts windows junctions to a cywin symlink Adrian H
2015-11-02 20:05 ` Andrey Repin
2015-11-02 23:32   ` Using cp converts windows junctions to a cywin symlink; a security-config override Linda Walsh
2015-11-02 23:50     ` Andrey Repin
2015-11-03 13:20 ` Using cp converts windows junctions to a cywin symlink Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).