X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; q=dns; s=default; b=qxZQN
	56zghERpsFea+hHFTpdOeHTnm9fidDfKywghX2bGeiiHw8c0VknR1wjXrX4ABKmi
	V/g8bufVsMW1DtNrA+D7vcJIHNVrZxn4NRgpqEhYR9TPdy0wGBEpvtIx/8TJpQbr
	dI8vr4gVkMvl//tccJC2feaaRwGdrsdf0eXaak=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; s=default; bh=rioAzy/Eubf
	Bp0Z/voIg5tpkqyc=; b=puQn/DDQAemxh8+7P39RiUdavQEHss77XtRiQp1E87Q
	D+TJStoCG5Ovt9h2uHZnlEh941wF7GgGsNInv41+x5N0m8YG/R3Ufp00HZp4Ln6B
	GziS3SrJlHu6E8VzsadXoUe5CSJLjQUz1qFZdDjQa9YS1deh+WSBazH+Ck0iyU2o
	=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
X-DKIM:	Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 3lTTw94QzPz4nSs
From:	Achim Gratz <Stromeko AT nexgo DOT de>
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
References:	<announce DOT 20150417103517 DOT GV3657 AT calimero DOT vinschen DOT de> <87pp72sei6 DOT fsf AT Rainer DOT invalid> <20150418083919 DOT GJ3657 AT calimero DOT vinschen DOT de>
Date:	Sat, 18 Apr 2015 11:47:01 +0200
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

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

- Raw text -