From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118313 invoked by alias); 23 Apr 2015 08:34:50 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 118304 invoked by uid 89); 23 Apr 2015 08:34:49 -0000 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 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Apr 2015 08:34:48 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 3D096A80973; Thu, 23 Apr 2015 10:34:46 +0200 (CEST) Date: Thu, 23 Apr 2015 08:34:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7 Message-ID: <20150423083446.GG3657@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20150421121559.GY3657@calimero.vinschen.de> <87a8y15rie.fsf@Rainer.invalid> <20150422090440.GB3657@calimero.vinschen.de> <877ft480zp.fsf@Rainer.invalid> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8MNCZdTuKvcKRZar" Content-Disposition: inline In-Reply-To: <877ft480zp.fsf@Rainer.invalid> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00534.txt.bz2 --8MNCZdTuKvcKRZar Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3559 On Apr 22 20:35, Achim Gratz wrote: > Corinna Vinschen writes: > > Hmm. Can you try the same with the latest developer snapshot I just > > created? I found this problem which created undesired DENY ACEs, > > maybe this was the reason /knock on wood/. >=20 > I ran out of time, but I've managed to install the snapshot and did a > quick test before going home. The ACL looks saner than before and I can > regain access via chmod, so that's good. The basic problem however > remains and I'm really not sure if that's a bug in rsync or in Cygwin or > even a bug at all. >=20 > The file to be copied has, as stated before, access granted only via a > share group (actually three of them, but that's not a factor). So > CREATOR OWNER, CREATOR group, the original owner of the file and myself > (owner of the newly created file) have no DACL entry on the original > file and the resulting file mode is "---rwx---+". For "rsync -av" this > means that after the copy the mode is set to 0060 and that explicitly > locks out (via DENY) CREATOR OWNER CREATOR GROUP and myself. That gives > the same POSIX modes, but not the same access rights of course. For > "rsync -av --acls" the same happens and then some ACL are copied over > from the original file, which still doesn't get me access since the > DENY ACL is first in the list. >=20 > This might be a hole in the ACL mapping to POSIX file modes. The way I > see it the reported file mode should actually be "rwxrwx---+" for the > original file since that's the effective access granted by Windows and > there are no POSIX flags on the original file (via NULL SID). Just like > on POSIX (where it's done via mask) the user flags can only be cleared > in this situation by an explicit chmod (which then gets implemented via > DENY ACL I suppose). You may be right here. The problem is that we have two kinds of ACLs to handle, the ones created by Windows means, and the ones created by recent or older Cygwin versions. It's rather bad that we can't distinguish them. But then, how do you check an arbitrary ACL for the effective rights it creates for all affected parties? I may be missing some API function. but I don't see a Windows function generating some kind of effective ACL. There's only the function AccessCheck() which gets a token and an ACL as input and then tells you the effective rights of the user with this token. This gets very slow and complicated, very quickly. I hate to admit defeat, but it also seems that the method I used to handle real vs. effective rights just doesn't work as desired. In theory we don't want the DENY ACEs having any effect before visiting the ALLOW ACEs. Ideally the DENY ACEs should only point out what the real access rights are, and they should secure the access against the next group, along the lines of NULL DENY user1 ALLOW # Only effective rights user2 ALLOW # ... user1 DENY # Point out real permissions, somehow Secure against excess group permissions user2 DENY # ... group1 ALLOW # As above group2 ALLOW # ... group1 DENY # As above, secure against excess Everyone perms group2 DENY # ... other ALLOW This needs yet another rewrite, but this will take a lot longer than this first cut. I guess we should create a new Cygwin release without this new ACL handling change for now to get the bugfixes out. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --8MNCZdTuKvcKRZar Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVOK6mAAoJEPU2Bp2uRE+g/MIP/j3ckblZuEIkHGnzXRTu9LqZ 35r7Zg7jaNppCVqNtUWL6eK0nlZeeB+aDdb02A9Qce4ygYq/kRYAYakxVV/q2LUv YO3RCZCQwYh1sFhWzNxeu4O5lnY+IDOaNxRDbHjs3dtQEpWDoZH2NfFvFBRALC1d sWifVZwkU3MsKlPaxA/IRKMZq/XktiisoWXcmRVIZa0RgrAtmSL8DyJYt/yIHwFy HLnhu0FMU0jVyw7SGxain/Eo9ljLm9k7OXqLr++eAqY7VYNKUxGiMU94sO1X0eTS yJ7Ic53H8FL2Y6seOURPgUmxW1GJ/fXjhMaJea56GzF9uuNu0iuIJ0uRHjBcoPFy iLWdZR6n8RJ/VYNYSIBKHrqr20Nrvq0+0A3S5uxjFetSX3ec8AINsD5sR9VvsqNe VB9SFIlnu5Jut7B1tye6uQiL3kZRZV38p4bI/53lKVneWJX/eaWlr90ZsGtkUE5p CiD/np3goi2L/4VaYB6PCvdAvVO9NAXRAepfyt1Ze7WU1c5FiBJ++R5xlwlJVicd tIQpqQmjLPRc59mpn+8gBjApdAhSFvapjECOS3dNs5T2tiXmD9hsB0r3ecaOiztf M5/3lR9/lC1NMNbiqJznJmRYF4+Sgoy3t4c75pb+3L0FV5KUoj7TVHCQ1bugb5WA RG9CJ2nUp19yB0L51pPe =WWPC -----END PGP SIGNATURE----- --8MNCZdTuKvcKRZar--