Message-ID: <4CD43740.8030006@redhat.com>
Date: Fri, 05 Nov 2010 10:56:32 -0600
From: Eric Blake <eblake@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Mnenhy/0.8.3 Thunderbird/3.1.6
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Executable bit check
References: <76B81B8B64B6254B98733990F38621DA6A0F@sron-chi-exc05.ronin.roncap.com> <4CD35A71.3030707@cygwin.com> <76B81B8B64B6254B98733990F38621DA6A13@sron-chi-exc05.ronin.roncap.com>
In-Reply-To: <76B81B8B64B6254B98733990F38621DA6A13@sron-chi-exc05.ronin.roncap.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE6A0353A075D3C2659247013"
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

--------------enigE6A0353A075D3C2659247013
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/05/2010 09:55 AM, Illia Bobyr wrote:
> On 11/4/2010 8:14 PM, Larry Hall (Cygwin) wrote:
>> [...]
>>>>> What does 'getfacl abc' say?
>>>>
>>>> $ getfacl abc
>>>> # file: abc
>>>> # owner: ibobyr
>>>> # group: Domain Users
>>>> user::rw-
>>>> group::r--
>>>> group:SYSTEM:rwx
>>>> group:Administrators:rwx
>>>> group:Users:r-x
>>>> mask:rwx
>>>> other:r--

And you probably also have inherited ACLs set on the directory
containing abc.  If you change the directory's ACLs to quit giving
inherited rights to all new files created in that directory, then new
files won't have ACLs that allow execution for SYSTEM, Administrators,
and Users, even when it does not allow execution for the owner, owning
group, or world.

>=20
> I wonder what is the behavior on any other system.  Is there anyone with=
=20
> a variant of Unix or Linix with ACLs set up to do the same test?

On Linux:

$ setfacl -m mask:rwx d/f
$ getfacl d/f
# file: d/f
# owner: eblake
# group: eblake
user::rw-
user:dummy:rwx
group::rw-
mask::rwx
other::r--

$ chmod -x d/f
$ getfacl d/f
# file: d/f
# owner: eblake
# group: eblake
user::rw-
user:dummy:rwx			#effective:rw-
group::rwx			#effective:rw-
mask::rw-
other::r--

Interestingly - that means that on Linux, chmod -x changed the mask
entry of the ACLs, such that the effective permissions for the alternate
user are no longer permitted; so even though user dummy has rwx ACLs,
the mask prevents the user from executing the file any more.

Cygwin does not emulate Linux in this regards at the moment, but now
that you have pointed out a simple test case, it may be possible to
patch cygwin1.dll to make the chmod() syscall affect the ACL mask as on
Linux.

> Maybe there is any de facto standard?

ACLs are tricky beasts.  At one point they were proposed for
standardization in POSIX (1003.1e draft 17), but that was withdrawn, so
there's no common document to point to when describing how they should
work.  There are at least 5 known variations of OS interfaces to acls
covered in the gnulib code that underlies coreutils' efforts to preserve
ACLs when using cp -p.  Cygwin's version borrowed more from Solaris'
heritage than Linux.

--=20
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


--------------enigE6A0353A075D3C2659247013
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJM1DdAAAoJEKeha0olJ0NqiKQH/1qMz3WS/n7RVP4GD+7T86AU
79jruXe8Ps0ZmEYLCqcoiBlLpSdftfAbpKBDENQAEVOh4B5fbl2LjVNZzeI7dJg0
EinrLFa58qu9WVBjZToa0EHbEokHBZsQZNt06TY+J7l6Tvb/DBqcgdrtah9J03VJ
IiOXdOfrd/dw0KO9TwOVBF1KyKU09IDV2mO+ourQeCqlFFvK8/eULJZIisNbQzfQ
lr48+8i8hS9xjfk0kyeI0Nl4IFOPAu1M2vGwNgxItbHlpSOmm26FSlP9XbLo7/Aq
FTE4gtVKYNYHBbbf2XK/NicXIu3AlaUaGMXHNDNTgqBYSHgubJGnqtiYvoWW28c=
=B0Jy
-----END PGP SIGNATURE-----

--------------enigE6A0353A075D3C2659247013--