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=v+u++EeEyk8602dQ1VtOxtCktxeLJxG9il26xjrauDVBKVVdrTmSd
	Zx/XLWjlQ9QrwPJ7+C/XP8/6dkgepfsSo/1RoHRP18ksRAQv/s5B9PeBcUW8VPcT
	/Q8/5U7ut/1uXsZI0MTVtXnVQX79AHp5C7h8pB2YAwLyk814NBW3rU=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Fri, 29 Aug 2014 10:28:59 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: ACL behavior in Cygwin // Re: (call-process ...) hangs in emacs
Message-ID: <20140829082859.GA20700@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <53F1F154.1020702@cornell.edu> <53FB87DC.2050908@cornell.edu> <87wq9v9j2y.fsf@Rainer.invalid> <53FD0662.5050208@cornell.edu> <20140827084245.GD20700@calimero.vinschen.de> <17910052714.20140828010203@yandex.ru> <20140828100112.GQ20700@calimero.vinschen.de> <187704841.20140828172337@yandex.ru> <20140828141036.GW20700@calimero.vinschen.de> <1833268701.20140828210041@yandex.ru>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="HSHpc5A+GJc9BHcd"
Content-Disposition: inline
In-Reply-To: <1833268701.20140828210041@yandex.ru>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Aug 28 21:00, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>=20
> >> > It's what "acl" means on Cygwin.  "acl" means that Windowsd ACLs are=
 used
> >> > and permissions are handled and converted to and from POSIX permissi=
ons.
> >> > "noacl" means, Cygwin ignores all ACLs and fakes ownership and POSIX
> >> > permissions only based only on filetype and DOS R/O attribute, as it=
 has
> >> > to on filesystems not supporting ACLs, like FAT/FAT32.
> >>=20
> >> Got it.
> >> It seems, Cygwin need a middle groung between these two for cases, whe=
re FS
> >> support access control, but don't want to be mangled.
>=20
> > I'm certainly not going to introduce another mount mode.
>=20
> I didn't said it has to be mount mode... besides, it doesn't make sense to
> implement YA mode to do what is already done, just a little different.
>=20
> > What Cygwin could do is to perform ACL-based access checks independentl=
y of
> > the "acl"/"noacl" mount mode on FSes supporting ACLs.  However, if you =
want
> > ACLs, why not use the "acl" mount mode in the first place?
>=20
> ACL inheritance, mostly. POSIX'ized permissions break inheritance on newly
> created files, at times making these files inaccessible to native
> applications, even though inheritance rules would allow it otherwise.
>=20
> > Still, it *might* makes sense in some scenarios, even if the results of
> > stat(2)/acl(2) may differ surprisingly from what access(2) returns.
>=20
> > We can also simply try it out.  A patch to enable this behaviour is
> > dead-simple.
>=20
> > Here's the prerequisite:
>=20
> >   Would more than one person want that *and* be willing to give this a
> >   *thorough* testing?
>=20
> I'd like to hear out expected behavior from this patch first.

Same output from stat(2), different output from access(2).  Access(2)
would only take the actual Windows ACL into account and let Windows
functions decide about granting or denying the requested access.


Corinna

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

--HSHpc5A+GJc9BHcd
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUADnLAAoJEPU2Bp2uRE+glm4P/ik4NcS+egD/9enWGZ2kuWMD
S+2RMFjTku1yBmPeNo0zBXtnHLIkA3Z99qybL5ujCJzSl5WMUZAUqxWFhH1NXJpW
Fu75hsrlBLxSUf8+v3E5I114FA4jO2eKTJppgm5hZ7EFBJmSJTN22EuukAPLIzKZ
MG2T6qx7BiiQx2cgQKhhJMotv9bXfq3tV+wJGIgRzb7ystbVoV1tEDZgVHKy8J45
YeRUKWmJ6IivMWagA1gj8e3U8RAiAxmcT9SGr3Lxwd4nxhDkVanQDSE7ki4AZM9Y
QIgBdthzCpjcYs108BzQiO+mSYltgWa1gszNf6yCnq5OV6p5ZS9JjLPwizJ8IFlL
wxl1K9YLparBzSjbQu2AwuB+OCQ88kyeQHUWsMnCnvqJ6RbU0EI0U+lXA69TBFzr
DROPFU+QUYQIIDsyWgamFVYCPQ1vo6cEer/HVQdW+R4K3RDrJIXnBcCTdAvJ/0BY
EIEpK/DlWjACPDozHNEONNbEBLi7XPvzNZiHFXs/d2vqwc7L4ySy3KPKWidam/6O
mWqj7ENHUeq1OrV0P/TVxKiErI5k8QmxQwWEwaA1+lWU0bHBzI7t3FIp1RIdLgPr
kVhuDfA3w+yjGNG1r/ldizv+Q7Dn5iDc88DUnfuaPEI25eSwTdztiDoIIjKBMtXV
9SHpO8oYdNVLvSzXTmTS
=DrOC
-----END PGP SIGNATURE-----

--HSHpc5A+GJc9BHcd--