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=kRt3/wnnU8Gx7hkf4y7b0ue8bCTI31gOHRM2HeUv41YQhjR8bm3vp
	8gVt+Y/aPozAfwWRIZkeVcAref1QM5Cn9gsu1KkAkumg69IHVH0r+ELRrIwpLfhY
	nwiipLSWa1In/845IoaKbRG2m50YG7MXU73QT+Mi+QOpcpoZv9c7/o=
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=J4NNXxVXNaQeMNXyxUpgGCr+aG0=; b=uXYsq7b7y9JEJV+xwyqFyd3Xg+la
	Awxb0rbmZ4FyJraEaYL1iaounLoakZXirCD9lCzQy9Rh/eom0PBMpVAX88s8Zmpq
	A9DI7b1VjW9F+PufaZRvC01Hvn5YTooiUwaP1X8xR7djTO6DN/Mbwzgqm5yYJI/w
	SR1tbDtaxc91o8I=
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:	Thu, 23 Apr 2015 10:34:46 +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:	<20150423083446.GG3657@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> <loom DOT 20150421T111734-742 AT post DOT gmane DOT org> <20150421121559 DOT GY3657 AT calimero DOT vinschen DOT de> <87a8y15rie DOT fsf AT Rainer DOT invalid> <20150422090440 DOT GB3657 AT calimero DOT vinschen DOT de> <877ft480zp DOT fsf AT Rainer DOT invalid>
MIME-Version:	1.0
In-Reply-To:	<877ft480zp.fsf@Rainer.invalid>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

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

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

- Raw text -