From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16193 invoked by alias); 18 Apr 2015 10:20:29 -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 16152 invoked by uid 89); 18 Apr 2015 10:20:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 18 Apr 2015 10:20:28 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 7FFF5A8084B; Sat, 18 Apr 2015 12:20:25 +0200 (CEST) Date: Sat, 18 Apr 2015 10:20:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 Message-ID: <20150418102025.GL3657@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <87pp72sei6.fsf@Rainer.invalid> <20150418083919.GJ3657@calimero.vinschen.de> <87h9sd4vl6.fsf@Rainer.invalid> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LWVQOr/QoF/fPPTS" Content-Disposition: inline In-Reply-To: <87h9sd4vl6.fsf@Rainer.invalid> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00436.txt.bz2 --LWVQOr/QoF/fPPTS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2613 On Apr 18 11:47, Achim Gratz wrote: > Corinna Vinschen writes: > > In theory, the access(2)/faccessat(2) functions should not rely at all > > on the new code. The reason is that they are implemented using the > > underlying OS function to evaluate ACLs. That means, they provide the > > actual access the OS grants. >=20 > That means they do not lie to the user like the mode bits do. Which > breaks all sorts of assumptions that POSIX programs are allowed to make. > In turn one will almost universally have to remove the corresponding ACL > grants (the inherited ACL will always have rwx modes) when using an > administrator account (in this particular instance that's an easy thing > to do, luckily). This kind of brings us back to where we started with > the discussion of whether to handle SYSTEM and Administrators specially, > only that the point of decision is now moved from mode check to > (f)access(at). The outcome is the same: if you can't remove those ACL, > then correct POSIX semantics aren't possible. Right. It's a compromise. I take it you don't like the extra behaviour for SYSTEM/Admins. Neither do I. Others are desperately waiting for more. The problem with compromises is, they are usually best if nobody is completely satisfied ;) As I said before, this behaviour is not necessarily the last word. We have to see how this works out. The point you're making here is certainly a point against this implementation. But I'm willing to defend it to get more testing. > > In the above case, SYSTEM and Administrators both have execute > > permissions, because they are never masked if they are secondary > > accounts, as outlined in the test release announcement. >=20 > A POSIX program trying to shortcut the ACL handling would conclude it > doesn't need to look beyond the mode bits. A program that checks with > faccessat anyway gets told a different story. The only analogue to this > is with root having implicit access to files on UN*X systems, but I > think "executable" would still be determined from the mode bits in this > case. Uh, not quite. POSIX defines If any access permissions are checked, each shall be checked individually, as described in XBD File Access Permissions , except that where that description refers to execute permission for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --LWVQOr/QoF/fPPTS Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVMi/pAAoJEPU2Bp2uRE+geeMP+wWhdMorD40Bi60XPgybGv67 xs8Y6P0jaSML3kHYOW5g2LCSVXpAtDOp8iCJOEVvwhK+TZeITYBVN66nokUOUhzV mNfuB71qbgLZNUStHqffqTzw/eKxj9R17WIETsGgji5zzfU/Y5a+rsiE/8Rp6zbF IAZhkrzQMA1oQXCdyUfAB5E8aLjfBod2J2HAdqio3gti5ygnwetOE5dB+0LzPPVb o6tbwX8+D5EPORnPLyS+dA8hYQnRwlAqZ2H339KH+m+XqE0gjp0nKItxM7iKQhqQ kEOndzc05c+piIGktIh2JFB3lpGc+yBdMra08nUR0TYwSwCaRrqKYn0n6rfsuP7Z Jl+a1pv1a1E4cB20XMXvJelv7OfT8lgEbRbESXYWfmu+KiIJlWD/s4r7oEwBzKsJ ZKOMtgz12pFhEoDGiDW1txNhoRL7b9HtE1+0yMzayJrW0l8cd9FdcDAf51BC8msH +CDo7o8wiAeWUJvr9kPFhp4ciHdWU7H93KaDCrhwYWjWXKWpQnJiN2EaERFS4tMJ /7wev2bRYLnXTvYx5mkbMQyT6wIOOkSu//7smSlxO2hXk3wKfCdxLuXrc0kuUs0P AkzQ+Z69O0EPqnju0KPaOPk7Hanepwk7Z5YgcbcrdxkgX9iGM02dRA/FcoONrIpr ehWmy11fmN6tM6TEtQVy =n19G -----END PGP SIGNATURE----- --LWVQOr/QoF/fPPTS--