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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=hFRz7YoTtlcAMDe7GzKU9uaqWbjszHE3wJjOu2QWvYwMTtiK0sSRC
	6E4WRlzXRCt1Snjrg3Yeh51f5gLTy44tcac/jigHCHkdqnhQUvKjezycRGJV8aBZ
	DCDSxgA28OqG2GvUp3zQwYVaaxWxMDbuVWRVT2pG3dWwEhCnNBj4ME=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=957rZ2WXF7jgBu02fYSMswND/dE=; b=B2F1mDn4mDg2K4iY64DYVpbxhUP/
	/HRH1flYO0+87ZmikFkd7Zltk+a8BDxlZFADHxx+PUZGt3rvZ7FwSzNUJ2rTgKPJ
	wwFZmoCxSOj6iJP3scHVpG8fsITfAdCWtI53fStYM0ZtImAKy6/yG032TnP6DP2E
	HsHCsYAyZC92N7Y=
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=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Sat, 18 Apr 2015 13:07:55 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
Message-ID: <20150418110755.GM3657@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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> <87d2314srf DOT fsf AT Rainer DOT invalid>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="D+WCZLadiceW8Bs8"
Content-Disposition: inline
In-Reply-To: <87d2314srf.fsf@Rainer.invalid>
User-Agent: Mutt/1.5.23 (2014-03-12)

--D+WCZLadiceW8Bs8
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 18 12:48, Achim Gratz wrote:
> 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 ;)
>=20
> 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.

Neither am I.  We're walking a fine line between two very different
systems handling ACLs.

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

Hang on.  As far as access(2) is concerned, Cygwin can't ignore the
execute permssions since the OS has its say here.  I don't think it's
overly helpful to tweak the result after the OS returned it, dependent
on the user being SYSTEM or having the Admins group in the token.
That's a lot of extra work for a questionable gain.

What we *could* try to do is to tweak the actual SYSTEM and Admins ACE,
though.  Rather than ignoring the CLASS_OBJ/ACL_MASK value completely
for them, we could apply the execute bit part only.  Usually it doesn't
make sense for SYSTEM/Admins having execute perms if nobody else has
since it's with high probability no executable file.

Would that make sense?


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--D+WCZLadiceW8Bs8
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVMjsLAAoJEPU2Bp2uRE+gXf0P/RwsaQtCaFPg6R6S7gtQcQIO
EORtYKkk7Jb7Am2vT72dZ9ebkBJH5Mw40GobrmmZsEYsPTGX7IT5mancBVVemDX8
W2PABL/pyQ+j7ViBb4GDmEQepfOHDPWuUBk5+qHOHpvm5J7HQiUmV2fhXxg68eFz
TliTf2GV7bMhXqs4D/LWplGKt51DDgl2Rks+1aPvvywfoXDEKbH7iLYBcjd279pA
KmHX14GSvwRp+8n7bmpraEqMprdKZ8IOj+H8Ds04ERbcZz3yOF543MoWywoHrnp2
jhuViq6bZI0AImxk+xKZCAifMygCD6rc9cR2mXOkkS/ZhSKK5QifC+E3ezpJmOuI
ZJRkP6LxfbMjh4Xi9BLQUKgHTcQ4cfkaMYvjRBHlEin+Q6gjQ2DtBOt2wvq2HVOR
Oa7AL5pRAHyoDXIqHKWI2ds28RcsJinfgF9dthi9eAZeEjHyLSyKOHWe/U5Kvr30
DJNE//CgXfzMIVZNpJgUa9pBLCCukJA+W2wRLE8besnNIZ7OOSkqkB3h/Otsvdyp
Nl1wQrYc/wVMIHJlIvx8iBuvSFV77y7A/Ph3mMGQDnBxP+YKEp+a1NGp5wToY9XU
5S7JG97eEN091CqS3dHHIaKdp9Yiybsjdb+cBXaAl00HsAJ1OjS6++fCUmhgMlJ/
8hcXeo46HiTHStSOaN3x
=k11u
-----END PGP SIGNATURE-----

--D+WCZLadiceW8Bs8--