delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2015/04/18/04:39:45

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=GnxLZxt3cj7vdXIT0lISIBes1HvdBXvSy0BPs/5sh1MzvAjSvtxTN
UFEHFghnu4vQgita5m4dzzyqJ/aoV65+n9YuQ62Nb2UphhKN+5XDzvEKQ2NoAxl3
XsRwhGuPjelrg+D5l2SrZXdukLFPYCnu4FA+TCtQxQvOyksdbFI3GU=
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=U3vR0m4LL/BRWCzkLm2u1qYPaOs=; b=NCTbZKReG8S/LS69EaN4uPbF9Gkc
Zsqf9Uc8eIISOixAtVLf26+8+4X5mgze+OfYDhi1yxe5mGokdYj2hds4k5KOkjgk
mP7WDhOrlJpV6pCJ2xnSd+xiELFWbjmRS1y8dBcUCz5IteyDo/sXugDqWRCpUA4N
+yx0OxKtnZkHLDY=
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 10:39:19 +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: <20150418083919.GJ3657@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>
MIME-Version: 1.0
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--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019