Re: (call-process ...) hangs in emacs

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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

> 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

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

Attachment: pgp2RKMl6yP_D.pgp
Description: PGP signature