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=bP84h
	qfRDbi6Q70nBQUH+0naeZ3HbuKs/bWz3HfRUbkzS65urXjlRQNJZTuAIuegmvX4A
	wMAunl1UiMA8F1h150mhVV59Zu+6iNfF84DlnNLPHBhIi4/TZa7ikagY+G+hQM2j
	ZT9UkptaHHQGEGY2xcrzK6r1OoDkRz2CISeAJU=
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=FEskPxmHaKP
	LkgfX2chhKMKhs1I=; b=QziJ9EsIR2qbXg9TVRpr4IgSrzqFuLTzee8IKOK5scx
	9NKNX+8ABhrukN1p47fs/eo03dk2TzyIbXdbDou44w9MZCua95uL7JLK4kRVc00B
	X1TItbwTIGVPqlHhPrNRQU1pUdrvKcXLikS8g87Jke+y49a/afTuFYslsmda3mA8
	=
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-12.arcor-online.net
X-DKIM:	Sendmail DKIM Filter v2.8.2 mail-in-02.arcor-online.net 3lTWGY0MXcz1T2v
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> <87h9sd4vl6 DOT fsf AT Rainer DOT invalid> <20150418102025 DOT GL3657 AT calimero DOT vinschen DOT de>
Date:	Sat, 18 Apr 2015 12:48:04 +0200
In-Reply-To:	<20150418102025.GL3657@calimero.vinschen.de> (Corinna Vinschen's message of "Sat, 18 Apr 2015 12:20:25 +0200")
Message-ID:	<87d2314srf.fsf@Rainer.invalid>
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)
MIME-Version:	1.0

Corinna Vinschen writes:
> 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 ;)

I have argued against treating them differently, purely based on
consistency between the Windows and POSIX world (where possible at all).
Other considerations have prevailed (maybe rightly so), so I'm not too
surprised to find some inconsistency in the results.

> 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.

It probably works out OK for non-administrative users and prevents the
need for them to deal with Windows defaults they can't change anyway, so
that's a positive.  The problems when working with administrative rights
have just shifted to a slightly different place, but it seems you still
have to employ the same workarounds.

>> > 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.
>
> 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.

I don't think you'll find a UN*X system that reports executable
permission on a plain file simply because root accesses it (for a
directory it would do that of course).  The situation in the above case
is on the face of it different (the ACL actually has the executable bit
set), but as I understand you've been wanting to treat both secondaries
like the root account.  I think it would be more sensible to ignore that
execute permission on plain files when otherwise none is granted (since
chmod will never mask it).  That would eliminate another reason to
entirely remove the default/inherited ACL and I don't think it has any
consequences on the Windows side.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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 -