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=hBUx3hiAi6qqHM8X6C0AZ1TLZekvOd719iC/f3WJKD6bp8ZIzBGfV
	W4JRz+ugCwsk6QQWL8+cRgLkx9PP8xtOO7O1xM8ZuRrD0Kf4yQDAr+u3fJAKQRDP
	vQSGQrPrKzqDllFwQyslLi/Ol5pNPmY8ji3OAAT5QAKLE/6qhDJ6TE=
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=yocMLEwWJn+2LYPfn7z0JIRHzgg=; b=jEaFhjAEWcrwkV0vkKPjZR+bmFdN
	7OZX5sh1Orrmq204TfLsdxPudlgKi0QnfThEwnaxUBWNLbtPOrKhbiD9KNhH2w+s
	93eODzK2LiCQH7bfxAQItjFq317SZefFii/Fmm5VksMpyeW4mq4sv6CeiMQ9CR3t
	FfZE58C1NMca/OM=
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 21:49:08 +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: <20150423194908.GA13598@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> <20150423083446 DOT GG3657 AT calimero DOT vinschen DOT de> <877ft2ptuj DOT fsf AT Rainer DOT invalid>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
In-Reply-To: <877ft2ptuj.fsf@Rainer.invalid>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Apr 23 20:44, Achim Gratz wrote:
> Corinna Vinschen writes:
> > 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.
>=20
> I=C2=A0thought that this was the point of the NULL SID ACL entries?

I was referring to the old-style ACLs created by Cygwin.  There
are some subtil differences.  I have to think about that some more if
that difference is really relevant.  It's a dangerous job since Windows
ACLs can cause knots in the brain.

> > 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 functio=
n.
> > 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.
>=20
> Right.

For the records:  AuthZ *might* be the answer.  I never used it and
I need some serious reading up on it.

> > 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.
> [=E2=80=A6]
>=20
> I don't think the ACL rules on Windows are made for that due to the
> early-out aspect of their semantics.

Yes, that's why the ordering is relevant.  If the deny's follow the
allows, they are almost (but not entirely) irrelevant.  Thus they
can be used to store information.

> > 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.
>=20
> Yes, getting the fixes out and shelving the ACL part for some
> re-thinking seems like a good idea.

Yup.


Corinna

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

--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJVOUy0AAoJEPU2Bp2uRE+gyh4P/Ap6SSpDi2v3rLAALYn1Qx0a
MTLWnzkR81u2o+qwyuHHUpZR2M77NJEdSa5lxgCYaV1yjTF3bWamP7Uz6ww2GYgW
DGCsumepwDCnq2oIh7KyDJDSZvrD3jDCd09MiOBOQ2Pz8OkUL6jWwLZmjOwDpPhH
ZE/kGMAYykDSOo457U3mbIV3girUNwdfAVoM32KhTcBnS4woKztIANcuy069krFO
sU5bAMAwS8dvIaOtvRedZucn2lMCupNyo3TCN3X2AXDpHMPFWJ0Wf5+VB3DjQDS2
EGFhUrjAISPnb8AieBVu5XYE7e6JIImP7ENy2KQzrVbcpEj6tKCfx68GlH96zdQK
SbtSMChzJB21qxXQrKH8VJTvH7rM1POMcZbR/WccrpJ6XQUHVAfC8rFr5WcJv8OO
6cswexZH7wZydHaXap0XmeCzXlTXOKrzlShFoEuOp3eKOvgB+g5Cih3TjgaXPa2b
hUOGy45J2eitmCI5rTUtH+PqCW/GWRqNrW9fH4dN7/SHBA+dF161c9LCxi6VOqti
QE9ZXq6p34B1bDCjFRXYwkTLCI8Rsp8+uzfIX3ufVOi8F+FW4ytv6Kp1bVl11lEn
YZV3uUDbSQRjbMtt9/n7bZI0XGAqYMTcljWAiIdSDNJ5Xt+z/WJNzfMcgm50pfBH
LokFuNPr0TBfOlVQlOUx
=3KMz
-----END PGP SIGNATURE-----

--3MwIy2ne0vdjdPXF--