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=Bl6qaHpDsj3s2edrBN97jRBzsnH25TRebBapbbAXnQ7QvB5TvjUWL
	tr0KP7Oaz7f+KExqjpT68pbCQxg+EsdhkEGLZ5kpA4Jb34bpV8Mr3r0FwwJR3NkS
	c/4jeS2M4mdhA14WlzPfqvzPxofiylDDMM/q8FbRJFSGSt+I7EmGT0=
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=DFrrC+mu3nSIgD3u0D36uLKMcJk=; b=HCq97luGRp0F0ajFvgqRhfMsdHnQ
	fh73PQDuEJ6k2BjTyHb3IcKM1C0ArD2lk4X5HBB2OsvUgH3jQ/VpatUQ8Cu5PYtI
	21yCZHae/q47/lYEVNj82iwpj5seO5q4Ym7xJWGGJj2X+i7DWcR1afbTcgXARpgW
	ozsb9XaAJ20dXnM=
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.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Thu, 28 Aug 2014 11:55:24 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: (call-process ...) hangs in emacs
Message-ID:	<20140828095524.GO20700@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<53E3F2AE DOT 7030608 AT redhat DOT com> <53E4D01B DOT 9010005 AT cornell DOT edu> <53F1F154 DOT 1020702 AT cornell DOT edu> <53FB87DC DOT 2050908 AT cornell DOT edu> <87wq9v9j2y DOT fsf AT Rainer DOT invalid> <53FD0662 DOT 5050208 AT cornell DOT edu> <20140827084245 DOT GD20700 AT calimero DOT vinschen DOT de> <53FDD4A8 DOT 5050401 AT cornell DOT edu> <loom DOT 20140827T170804-533 AT post DOT gmane DOT org> <loom DOT 20140828T085927-71 AT post DOT gmane DOT org>
MIME-Version:	1.0
In-Reply-To:	<loom.20140828T085927-71@post.gmane.org>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

On Aug 28 07:25, Achim Gratz wrote:
> Achim Gratz <Stromeko <at> NexGo.DE> writes:
> > Let's get one issue out of the way first that may be a Cygwin bug: on L=
inux
> > a file with all access removed via standard POSIX modes and then access
> > granted via ACL would place the mask bits of the ACL (the maximum permi=
ssion
> > that can be granted via ACL, usually rwx) into the group portion of the
> > POSIX modes (ls --color would even show these in different color if you
> > didn't happen to notice the "+").  That doesn't happen on Cygwin and it
> > seems that some software optimizes based on that information to not tra=
verse
> > the ACL when there's no chance to ever get a permission granted.  This
> > behaviour is mandated by POSIX IIUC (and it is what Linux is doing) so
> > unless Cygwin explicitly follows a different ACL model, I think that sh=
ould
> > be taken care of before diving into this further.
>=20
> As a concrete example, in the following the directory x86 shows up on Cyg=
win
> as follows:
>=20
> > getfacl x86
> # file: x86
> # owner: otheruser
> # group: Domain Users
> user::---
> group::---
> group:FilerAdmins:rwx
> group:ShareOwners:rwx
> mask:rwx
> other:---
> default:user::---
> default:group::---
> default:group:FilerAdmins:rwx
> default:group:ShareOwners:rwx
> default:mask:rwx
> default:other:---
> > ls -ld x86
> d---------+ 1 otheruser Domain Users 0 Jun 23 14:09 x86/
>=20
> Under Linux in the same situation you'd get
>=20
> > ls -ld x86
> d---rwx---+ 1 otheruser Domain Users 0 Jun 23 14:09 x86/
>=20
> instead (i.e. the mask bits shown in the group portion of the standard mo=
de
> flags).  If the file was owned by your uid, then you'd get indeed
>=20
> > ls -ld x86
> d---------+ 1 myself Domain Users 0 Jun 23 14:09 x86/
>=20
> but you'd also really have no permissions.  On Windows you do have
> permission to the file in that situation since the POSIX part of the ACL
> (particularly the user::--- part that revokes all access for the file own=
er)
> are faked by Cygwin and not taken into account when the file gets finally
> accessed:
>=20
> > icacls x86
> x86 DOM\FilerAdmins:(I)(OI)(IO)(F)
>     DOM\FilerAdmins:(I)(CI)(F)
>     DOM\ShareOwners:(I)(OI)(IO)(M)
>     DOM\ShareOwners:(I)(CI)(M)
>=20
> If getting at the correct mask is too expensive, simply always faking an
> "rwx" mask might actually be better than what we have now, since once the
> ACL are fully processed you'll get the correct permissions anyway.

Handling of the CLASS object (aka "mask") has never been fully
implemented, especially because there's no such thing as a CLASS object
in a Windows ACL.

I guess it will always be some fake, but, yes, we can try to change
stat() so that the st_mode group permissions reflect the or'ed bits of
all permissions given to non-primary users and groups.  Same in acl(2).
That might be useful.


Corinna

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

--cGfB/trNgB3WtPHu
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJT/vyMAAoJEPU2Bp2uRE+gfygP+wctJdWguguuTo/BaWAsj6o6
En+0Sy5I6FLGClOYylRmEv42zAg5nz8sb8geeX+Nf5flQE4EOdHWagwo+jjFjNzJ
sghvfAOhVHZzX/Ety5aWS6y11cJDqkydIPhQ+zBEjeWefu+/YHK9FiY847UYInbJ
PlN+7bl8ssQ3S8Un9AJNN34HiUYjwf/Lz1TY4HhO6pnX7p1zhleqU1tF5PJNw6R7
oe7repLj8dXO6oO/VJ6wLnD1A+o4OO0yHAC6z05y64FDnTYo7Yv5nDxyeSgEI0wF
coPvncwFFByDs+4x1+UWWL+c5UTpLW6byai9RM7rFZy0D0dt9KVzVtTE3tfoHmVg
BU0NO/xkFWs512tvsHiUNifEgifTCBH0a9opa9kuOW0QBqQNYgk11Q1yWvYO2jEL
XnVZlcGg4xr06tUSSBJ9XjACz1/qHlbCwSgZJkPWLJCTkl1L+a94S5Q61n63us8N
Y5CX50eS60QkERXNImJRue9kI91tMSodjfyq9rN8fh2nKn0wcpPByuGWfJs3tCn8
oRyWutWvEc3pviGV3tw/z2RJ1XTxk1Y5WFzbc9W76nMDuwroPq9CgW45PLhwo3dv
Wto9QJtVqKbAUUvia91Lq+7sD8a1c/vW9a7avsS+mMUETq1Il9o7FCRx7BmuxMPi
X953iLG75zI8bGBsj2jb
=CvSF
-----END PGP SIGNATURE-----

--cGfB/trNgB3WtPHu--

- Raw text -