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=ySALbpXgW9y3dG1Abs7iRJtGk4t4QX7YcOFw/PDE72hVKtDUGXsPa
	HL/URMMfry8F0SWMA9ofs6GsYIyj8bHw1gjCbejrlP4wi2OqLikkQBBbusi0ujCO
	uiuYeaCzDb3cSXU8RV0P+puQj3WhX4pZOf347A0/frC0FdI9CNXDXc=
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=PkB3n3GzKQVgVKSZ2EWVXU5G3uc=; b=BvJrXVsylzng0pQv8IyJpOyxp/bp
	jxb6VdNJKZ+V82wJSG3B/6qtaS8GFci5m7jsaXx9slpYF3ii1bGqB/SRUCkP2xkB
	ZWDmQxX6IovkYvQT3L34CwqdUnsuFZm0e42QgTu07HqZvLXcnmXz/3h/g+KWWcar
	SR+nJwzxo1pMZIA=
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: Tue, 2 Sep 2014 22:09:07 +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: <20140902200907.GA18235@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20140828095524 DOT GO20700 AT calimero DOT vinschen DOT de> <20140828131832 DOT GT20700 AT calimero DOT vinschen DOT de> <loom DOT 20140828T172529-396 AT post DOT gmane DOT org> <loom DOT 20140829T115632-276 AT post DOT gmane DOT org> <20140901115701 DOT GD2644 AT calimero DOT vinschen DOT de> <87ppffs0kw DOT fsf AT Rainer DOT invalid> <20140902083217 DOT GM2644 AT calimero DOT vinschen DOT de> <87mwaiq6bt DOT fsf AT Rainer DOT invalid> <20140902191914 DOT GG6056 AT calimero DOT vinschen DOT de> <87sik9q069 DOT fsf AT Rainer DOT invalid>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw"
Content-Disposition: inline
In-Reply-To: <87sik9q069.fsf@Rainer.invalid>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Sep  2 21:42, Achim Gratz wrote:
> Corinna Vinschen writes:
> > More or less, just compare the ACLs and see if you find strange
> > differences.  This only works for the ACLs created or modified with
> > `setfacl' and the snapshot DLL.
>=20
> I see, I'll have to make extra tests for this.  Usually I just have to
> live with some inherited ACL that I can't change at all.
>=20
> > The ACLs created or modified via
> > setfacl with the older DLLs always were different and, I have to admit,
> > kind of broke the default POSIX permissions created via open() or
> > chmod().  The idea of my change was to make them always in an identical
> > fashion.  The order may only vary in secondary permissions, but never
> > in the standard permissions, which also always come first.
>=20
> One thing I've noticed, but can't really say if it's related to the
> change, is that setfacl quite often claims an "illegal ACL" when trying
> to remove for instance the SYSTEM read permission.

  $ setfacl -d g:system: filename

Note the trailing colon.=20=20

> Removing the group
> owner ACL instead did the right thing in at least one instance.

??? It shouldn't.  Removing the standard ACL entries for the owner,
owner group, and other is not allowed:

  $ setfacl -d g:: filename
  setfacl: No error

The "No error" is a bug, related to the fact that the aclsort() function
doesn't set errno if aclcheck() failed.  I just fixed that in CVS.

> I've mostly been removing all ACL from the whole tree via the explorer
> security tab (for ~/.ssh/ and similar stuff).

*All* ACL???  That sounds wrong to me.


Corinna

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

--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJUBiPiAAoJEPU2Bp2uRE+gu6AP/0XFU1E4oyR+9LXbiw7KL2UX
OFkE5e9yHnEGQjErrNa+l/X8kvYAyh8bRBwE4VzSo/+vOIzHTHfKKCAzQ9nFxALM
zLEowPtVDzAWSeDtnad0JwynLI5rHCpvqIut2cIDx3dORJgIx6qx7eODJ05bL2G+
DxXjbJgHEqQxa6AvVzOtIFCwvKe6sirlN+zDENyJuKRAjsO7AaOmNtpyExGiUJtR
zlgcWrUYCjeEgBdqQ6h+pxqGDLm3FeM39Loc5GkS/si0Ol5SO6TWxBMJjh7JhtsW
y5yvXRpZOpfQzywR+BYkUR1qsBhSRUhAYDEPw8OqsRMfHuFxV2wxGOYQ5eS5LG8d
OgLDDf++o39UCD7H2108AnqA3sV6/yYe1hijiQUlE/DWeiPzWsUhrHUz7jrcO2qJ
X0Yhes2kUTLbbCNy3e0PRj/KnwXPXQ0MqA02Pykkzd+ysev3qDhzKczrz6W9Xbc+
YOhbrflCPORfYIXwlMrugYR9V3OUwIOdsRaDGVkqpcbbdegV7iHXSixATSxVmqMF
axdqFLje+JD/Cy4u7Qp700i3ft3105/80KgvlYATuLPD/lxfG3zpzW6aslo6yoxe
y/+usscZaMBfsa+ovlYEvA4epTO4LfWxzR2yUbANisBR3bNcwdL4xssr/4BRDkLA
49OdAvEcx8moiKuzjgWa
=YP3L
-----END PGP SIGNATURE-----

--GvXjxJ+pjyke8COw--