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:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=g+5aDbrpP7p+GjKXcWjlB9+qv/EXIVuS1EIfT3HjXBRbSKfv+BH/I
	qBtrXFO0IzRIUyBMhwHlvbGvRtQZF9hEO7f3aPraKHydLYk0mm4Gy7t4lraThStX
	r0AJqQONbB5HoMl71EkXXsPN8IOuft2UnMp7MzmiUN/d15LK34HWYw=
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:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	 bh=MNrvuh7o1DNBJ/pNTszN+8nOuVk=; b=LqenYVSpWwskxvX5y+1AdteplnB/
	sD0dBTFu0lbunk070jzmEA4bzO1n+NEDi85CcK5GHksWzXTzRQ2Crr2Upv8h3g8J
	zxQcuTlR9zXH9jpa7JKwtTrP7JepzRPCVZzM9k1SkzqUj2j71SCodNJP0cVcqtcQ
	cKKTblhm8BoFPk8=
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=-4.5 required=5.0 tests=AWL,BAYES_05,FSL_HELO_BARE_IP_2,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2
X-HELO: plane.gmane.org
To: cygwin AT cygwin DOT com
From: Achim Gratz <Stromeko AT NexGo DOT DE>
Subject: Re: (call-process ...) hangs in emacs
Date: Thu, 28 Aug 2014 07:25:09 +0000 (UTC)
Lines: 65
Message-ID: <loom.20140828T085927-71@post.gmane.org>
References: <20140805184047 DOT GC13601 AT calimero DOT vinschen DOT de> <53E3685B DOT 8050508 AT cornell DOT edu> <53E39BAD DOT 3010004 AT redhat DOT com> <53E3CB46 DOT 1020909 AT cornell DOT edu> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes

Achim Gratz <Stromeko <at> NexGo.DE> writes:
> Let's get one issue out of the way first that may be a Cygwin bug: on Linux
> 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 permission
> 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 traverse
> 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 should
> be taken care of before diving into this further.

As a concrete example, in the following the directory x86 shows up on Cygwin
as follows:

> 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/

Under Linux in the same situation you'd get

> ls -ld x86
d---rwx---+ 1 otheruser Domain Users 0 Jun 23 14:09 x86/

instead (i.e. the mask bits shown in the group portion of the standard mode
flags).  If the file was owned by your uid, then you'd get indeed

> ls -ld x86
d---------+ 1 myself Domain Users 0 Jun 23 14:09 x86/

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 owner)
are faked by Cygwin and not taken into account when the file gets finally
accessed:

> 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)

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.


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple