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=dx1+LrjpdLOaR8jkMoiO1FKDpuUzjjIvmrawm+j6oZICBF8CPFG+X
	+C1d1VKVR3N7vCrSRfA0uxTigw33fN1czt9JE/rmKwed5BmQ5K9J4ygCqt6EwWjx
	A1Gi/TqTpgHAfqp4iFR0w5ExIOFVP207ehkU6xCjWwfHqFsOUpcE54=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 24 Jun 2016 21:54:38 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: POSIX permission mapping and NULL SIDs
Message-ID: <20160624195438.GC27089@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <D392BA70.95D4%billziss AT navimatics DOT com> <20160624195144 DOT GB27089 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="MfFXiAuoTsnnDAfZ"
Content-Disposition: inline
In-Reply-To: <20160624195144.GB27089@calimero.vinschen.de>
User-Agent: Mutt/1.6.1 (2016-04-27)

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

On Jun 24 21:51, Corinna Vinschen wrote:
> On Jun 24 18:07, Bill Zissimopoulos wrote:
> > Could my mapping of the NULL SID somehow interfere with Cygwin=E2=80=99=
s ACL
> > mapping? No way right? Turns out that: yes! File:winsup/cygwin/sec_acl.=
cc,
> > line:787
>=20
> Read the comment at the beginning of the file explaining how new-style
> ACLs look like.
>=20
> > Allow me to say that I find this a *gross* hack. You are subverting the
> > Windows ACL mechanism to store information that it was not designed to
> > store. I would love to hear a good rationale for this decision.
>=20
> The usage of NULL SID ACEs to store special POSIX permission bits is
> long-standing behaviour, first implemented by U/Win and later adopted by
> Cygwin.  That older version is using Access-allowed NULL SID ACEs for
> *ages* to store ISVTX, ISGID and ISUID bits.  The new implementation
> uses access-denied NULL SID ACEs to store the same bits, plus the POSIX
> MASK bits.  Another access-denied NULL SID ACEs with the "Inherit Only"
> bit set is used to specify the same info for the POSIX default ACL.
>=20
> > BTW, this also appears to break BashOnWindows: see [BASHW]
>=20
> I'm not overly sympathetic.  Cygwin's implementation is older.  If
> Microsoft provides full support for POSIX permission bits plus POSIX
> ACLs including useful documentation, I'm willing to reconsider.  And
> matching patches are welcome of course.
>=20
> What strikes me as weird is that nobody from the UoW side is trying
> to work with Cygwin ACLs or even trying to communicate with us to
> define and implement POSIX ACLs in a documented, generic way for both
> systems.

And why on earth does an access-denied NULL SID ACE affect SoW *at all*?


Corinna

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

--MfFXiAuoTsnnDAfZ
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCAAGBQJXbY/+AAoJEPU2Bp2uRE+gYU0P/jRXllNBCz0ttXOefI3JfVv/
HvBGlQyF738PqksLHxvJQe9gty9kAu+Ft3fZuyu9oNtTOZQlglauarr5Jb4lyvQn
dQPx68xkiyw0nWueaE8rwLUHYWmuaufpUwUu7Ns+zEacjedTOUAIPSnhDWvS8aXO
WyN2gJxSXFmcqnLWdcm2z3zU23M6tRKdOOG2TUFFjI/oC4sK19ysnBHPIiOssD3X
RnDumydtTgX0Qe7w77ON/ATdcuUckN3/OAAJ6+m47k9mmz/wPZk/OOzB9j9UaMRv
ffLg5QwJFovEX8u0TT2wiA8WQeIZ/9X0S22fMYzlmVXKZFYgBOV92BRTrZtb0lKN
FaHtv+Ip3dz57/OS6aP4OBjqnOAAWgrZvyKGxVbBiiJBJTm8sYdYdgjMWe0wsRgw
ylS6SspqkXv1zBfU1sUa0y13gFUaWAPq8hvxFJxaNY18s7KKKzE0fnsex6mS8hXS
Kla8rJaq6v3qq1ja9luTkHvQcCPRkLq7q9fHl3BFC+j8wuYTAdgO/aRItQvmz3mx
Y+Z1Ayl14VzkkAGv6UeQNKGO6Jmn7pCqmxms0WcZNyUwAibnNxkp4qbj11K029tC
uAod0Af20f6+N2lDlSaCE/HC41tC0qcwBBUZ6r/u8mtnsqF3B3ifnHTyVG1D4ei2
9nNjz5cjQSNtxffrY88O
=oif3
-----END PGP SIGNATURE-----

--MfFXiAuoTsnnDAfZ--