(call-process ...) hangs in emacs

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Aug 28 09:55:00 GMT 2014


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

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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20140828/7978ada3/attachment.sig>


More information about the Cygwin mailing list