X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_13,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <6910a60908101701m77bcb1b3x55e48d028bf35ef0@mail.gmail.com> References: <20090810132515 DOT GP3204 AT calimero DOT vinschen DOT de> <20090810164057 DOT GV3204 AT calimero DOT vinschen DOT de> <6910a60908101701m77bcb1b3x55e48d028bf35ef0 AT mail DOT gmail DOT com> Date: Tue, 11 Aug 2009 04:49:18 +0200 Message-ID: <6910a60908101949k5f2ce354p1ccda7f2acd9927f@mail.gmail.com> Subject: Re: Perl bug (was Re: [1.7] cygwin allows writing to readonly files) From: Reini Urban To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 2009/8/11 Reini Urban: > 2009/8/10 Corinna Vinschen: >> On Aug 10 20:11, Alexey Borzenkov wrote: >>> On Mon, Aug 10, 2009 at 5:25 PM, Corinna >>> Vinschen wrote: >>> > That's a bug in your testsuite. =A0I assume you're running the tests = as >>> > administrator, right? =A0Administrators have the right to write to all >>> > files, even R/O files, according to POSIX rules. =A0Your test would f= ail >>> > on Linux as well, if you're running it as root. >>> >>> Well, it's not my testsuite, but yes, I'm running under administrator >>> account. But it makes me wonder, how does it work? Do you change ACLs >>> temporarily? >> >> No. =A0It's a "user privileges" thingy. =A0See >> http://msdn.microsoft.com/en-us/library/aa379306%28VS.85%29.aspx >> >> The SE_BACKUP_NAME and SE_RESTORE_NAME privileges are in the >> administrator's user token, but they are not enabled by default. =A0Cygw= in >> just enables them at startup time, if they are available in the user >> token. =A0Therefore, a Cygwin process has the usual POSIX-like permissio= ns >> for admin users. =A0It's no magic which isn't available to any other >> native Win32 application. >> >>> Anyway, it means there is a bug in perl, because on Linux: >>> >>> root AT kitsu:~# touch test.txt >>> root AT kitsu:~# chmod 0444 test.txt >>> root AT kitsu:~# perl -e 'print "writable\n" if -w "test.txt"' >>> writable >>> >>> On Cygwin 1.7 perl thinks that the file is not writable. >> >> Indeed. =A0Checking with strace I found that the test is the same on Lin= ux >> and Cygwin. =A0In both cases perl uses stat(), and the returned permissi= ons >> are the same (0444). =A0Further experimenting shows that perl has a >> hardcoded uid =3D=3D 0 test which must obviously fail on Cygwin. =A0If I= change >> the user's uid to 0, the string "writable" is printed by the above comma= nd. >> >> That's a bug in perl. =A0There are other OSes out there which have >> root-like permissions for non-0 uids. =A0Perl should use the access() >> function to check for read/write/execute permissions, which always >> returns the correct result independent of the uid of the current user. > > Thanks. > I'll carry it along to p5p, but it will definitely not appear in > upstream 5.10.1 > because this gate is already closed. > Even a horrible performance problem with > File::Spec::Cygwin::case_tolerant was not fixed. > > But I work on a fix to be included in blead and in my cygwin package. Bug confirmed too early. It's actually defined and described this way. access() is not used for performance reasons. See perldoc perlfunc -X If you are using ACLs, there is a pragma called C that may produce more accurate results than the bare stat() mode bits. When under the C the above-mentioned filetests will test whether the permission can (not) be granted using the access() family of system calls. Also note that the C<-x> and C<-X> may under this pragma return true even if there are no execute permission bits set (nor any extra execute permission ACLs). This strangeness is due to the underlying system calls' definitions. Note also that, due to the implementation of C, the C<_> special filehandle won't cache the results of the file tests when this pragma is in effect. Read the documentation for the C pragma for more information. $ ./perl -e 'print "writable\n" if -w "test.txt"' $ ./perl -e 'use filetest "access"; print "writable\n" if -w "test.txt"' writable I can turn on access checks easily for CYGWIN but cygwin perl is already slow enough, so I will not do that. Changing the uid=3D=3D0 check to check the Administrators gid is more promi= sing. i.e. --- doio.c.orig 2009-04-18 19:17:04.000000000 +0200 +++ doio.c 2009-08-11 04:46:09.343750000 +0200 @@ -1918,7 +1918,11 @@ return (mode & statbufp->st_mode) ? TRUE : FALSE; #else /* ! DOSISH */ +# ifndef __CYGWIN__ if ((effective ? PL_euid : PL_uid) =3D=3D 0) { /* root is special */ +# else + if ((effective ? PL_egid : PL_gid) =3D=3D 544) { /* member of Administrators? */ +# endif if (mode =3D=3D S_IXUSR) { if (statbufp->st_mode & 0111 || S_ISDIR(statbufp->st_mode)) return TRUE; but this didn't help me, because Administrators is not my first group. So I call this a known limitation for all ACL aware filesystems. --=20 Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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