From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88450 invoked by alias); 2 Nov 2015 23:32:35 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 88438 invoked by uid 89); 2 Nov 2015 23:32:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_50,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: Ishtar.hs.tlinx.org Received: from ishtar.tlinx.org (HELO Ishtar.hs.tlinx.org) (173.164.175.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 02 Nov 2015 23:32:33 +0000 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.9/8.14.4/SuSE Linux 0.8) with ESMTP id tA2NWR1S061538; Mon, 2 Nov 2015 15:32:29 -0800 Message-ID: <5637F28A.40104@tlinx.org> Date: Mon, 02 Nov 2015 23:32:00 -0000 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: cygwin@cygwin.com, adrianh.bsc@gmail.com, anrdaemon@yandex.ru Subject: Re: Using cp converts windows junctions to a cywin symlink; a security-config override References: <1667216939.20151102225151@yandex.ru> In-Reply-To: <1667216939.20151102225151@yandex.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00053.txt.bz2 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