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=GnxLZxt3cj7vdXIT0lISIBes1HvdBXvSy0BPs/5sh1MzvAjSvtxTN
	UFEHFghnu4vQgita5m4dzzyqJ/aoV65+n9YuQ62Nb2UphhKN+5XDzvEKQ2NoAxl3
	XsRwhGuPjelrg+D5l2SrZXdukLFPYCnu4FA+TCtQxQvOyksdbFI3GU=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Sat, 18 Apr 2015 10:39:19 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
Message-ID: <20150418083919.GJ3657@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <announce.20150417103517.GV3657@calimero.vinschen.de> <87pp72sei6.fsf@Rainer.invalid>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="Iv4H2WyLgK50POYH"
Content-Disposition: inline
In-Reply-To: <87pp72sei6.fsf@Rainer.invalid>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

Hi Achim,

On Apr 17 22:09, Achim Gratz wrote:
> Corinna Vinschen writes:
> > New 2.0.0-0.7 test release:
> >
> > - Improved setfacl tool.  It now handles mask recomputation just like
> >   the Linux tool.  -d option renamed to -x (but -d is still accepted
> >   for backward compat).  New -n,--no-mask and --mask options.
>=20
> "setfacl -b -k" still errors out instead of removing both the default
> and extended ACL entries.

I didn't work on that, but patches are welcome.

> > The important change in this release is the POSIX permission handling
> > change, a rewrite of the underlying routines reading and creating
> > Windows ACLs following POSIX permission rules and POSIX ACL creating
> > rules per POSIX 1003.1e draft 17, as on Linux.
>=20
> I seem to have found another fly in that ointment (or rather cygport
> did find it for me=E2=80=A6):
>=20
> While packaging a "find usr/ -type f -executable" would find newly
> created info files that ls and getfacl agree are not executable:
>=20
> -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:---
>=20
> 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?

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.

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.

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.


Corina

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

--Iv4H2WyLgK50POYH
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJVMhg3AAoJEPU2Bp2uRE+gXJsP/RZwFRGnFCHvSBXeizuz/vba
j+UTkN2HStQLGKKoNp5BfQmS18KYFEX0CImYTYm9nxluJT/O8SxeQi6t56ZGhIX/
jJKAKsRaG7XmBmOTD6J0+37wY4Uwk4BTch2HUDbkmMA1htLT3FaQRuqI1WQpx5eb
aBf/LH1O3jDroC/wsesGrSYfdASi9fd+JTeeSiMoxplvZoc8l7mjRU6GKMkqvP6l
5pS4KTNz8r5tCeKgE6gT2ODQ2f46n8BExso2q5gqvUl5d3LquNSI06UsvxQsOT54
aA8khDEIgyC6l6zc9I352HTEecf9TXHBDmy1BImWmXxssVduk+075PuAER8sbsRG
7r9LCS97dA+CQVYrenNGoMLON0hQrgk0INRn3RGqft5CaJ3bfrZImE30y+JMiKGr
Iv2+BrFQ0AN/tE5kWyvppsfjzCzmX4OvTcF/L0lO3PNAyMtjXG0Yg+tjoj8bZbEJ
Xy/mSzuqETFZ56fxciTd2FkZRxKUXD3LRjtJQRqeqGvrJQxmAjYE5A1yzvEpNFW/
UqzWI5y7QJRJinBbi3+10Wro6dUkg8+apHkmoTv7ge9TbB1h1cnbxeo6NjNO3oCb
vHNQbSCfNwe6UzqbgaZby70NV2CipnywCx8tEzaENoz3eZ95EB9LxEP7n30ffLyX
DbZfgUvZTsKM0vZC5Ho3
=AjrG
-----END PGP SIGNATURE-----

--Iv4H2WyLgK50POYH--