From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90463 invoked by alias); 18 Apr 2015 09:47:12 -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 90450 invoked by uid 89); 18 Apr 2015 09:47:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-in-03.arcor-online.net Received: from mail-in-03.arcor-online.net (HELO mail-in-03.arcor-online.net) (151.189.21.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Sat, 18 Apr 2015 09:47:09 +0000 Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mx.arcor.de (Postfix) with ESMTP id 3lTTw95lRvz6fJm for ; Sat, 18 Apr 2015 11:47:05 +0200 (CEST) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id C245F3C9838 for ; Sat, 18 Apr 2015 11:47:05 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 3lTTw94QzPz4nSs Received: from Gertrud (p54B46CC7.dip0.t-ipconnect.de [84.180.108.199]) (Authenticated sender: stromeko@arcor.de) by mail-in-14.arcor-online.net (Postfix) with ESMTPSA id 3lTTw94QzPz4nSs for ; Sat, 18 Apr 2015 11:47:05 +0200 (CEST) From: Achim Gratz To: cygwin@cygwin.com Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 References: <87pp72sei6.fsf@Rainer.invalid> <20150418083919.GJ3657@calimero.vinschen.de> Date: Sat, 18 Apr 2015 09:47:00 -0000 In-Reply-To: <20150418083919.GJ3657@calimero.vinschen.de> (Corinna Vinschen's message of "Sat, 18 Apr 2015 10:39:19 +0200") Message-ID: <87h9sd4vl6.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-04/txt/msg00434.txt.bz2 Corinna Vinschen writes: >> -rw-------+ 1 ASSI Kein 48880 5. Apr 2014 ucl.log >> # file: ucl.log >> # owner: ASSI >> # group: Kein >> user::rw- >> group::--- >> group:SYSTEM:rwx #effective:--- >> group:Administratoren:rwx #effective:--- >> mask:--- >> other:--- >> >> It seems that some of the code doesn't take the masking bits into >> account just yet. Here's the relevant portion of an strace on a >> different file (I had already deleted the ACL on the original ones): > > What means "deleting the ACL"? You always have an ACL in some way, no? > What does getfacl and icacls print after the delete? It means "setfacl -b" in this case. Which removes the (inherited) ACL for SYSTEM and Administrators. > 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. 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. > 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. 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. > So the result of access is the real thing, while the above output from > getfacl is wrong. My bad. It should never print an "effective" value > for SYSTEM and Administrators, but I forgot to handle them explicitely. > I'll fix that. Thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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