This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: (call-process ...) hangs in emacs
- From: Andrey Repin <anrdaemon at yandex dot ru>
- To: Corinna Vinschen <cygwin at cygwin dot com>
- Date: Thu, 28 Aug 2014 17:23:37 +0400
- Subject: Re: (call-process ...) hangs in emacs
- Authentication-results: sourceware.org; auth=none
- References: <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> <17910052714 dot 20140828010203 at yandex dot ru> <20140828100112 dot GQ20700 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
Greetings, Corinna Vinschen!
>> > faccessat/access/eaccess don't try to be intelligent by themselves.
>> > Rather they just call a Windows function if the filesystem is mounted
>> > with "acl" mount flags:
>>
>> > - Fetch file's security descriptor
>> > - Create process impersonation token.
>> > - Call NtAccessCheck
>> > - If NtAccessCheck returns "not allowed", check for backup/restore
>> > privileges via NtPrivilegeCheck.
>>
>> > In "noacl" mode or on filesystems not supporting ACLs, access uses the
>> > st_mode flags from stat() to figure out the permissions.
>>
>> I'm not very much into Cygwin internals, so beg pardon if I got something
>> wrong here... But reading this makes my internal sanity checker go into red
>> alarm state.
>>
>> Here's why:
>>
>> When Cygwin mount a filesystem with 'acl' flag set, it mangles current ACL's
>> set on the files to produce something that can be understood as basic POSIX
>> 'ugly'...erm, 'ugo' permissions. Behavior least desirable in many cases.
>> You say, it will then use native functions to determine access rights... No
>> wonder they will work, since you already mangled them to suit your needs.
>>
>> When Cygwin mount a filesystem with 'noacl' flag, thus let OS use true ACL's
>> (a feature Windows implemented surprisingly fast, while *NIX was only
>> proposing it... for far too long without any result in sight), it is then
>> followed by some magic and guesswork on Cygwin's end to find out access
>> rights.
>>
>> If you ask me, something isn't quite right here. Or something is missing.
> It's what "acl" means on Cygwin. "acl" means that Windowsd ACLs are used
> and permissions are handled and converted to and from POSIX permissions.
> "noacl" means, Cygwin ignores all ACLs and fakes ownership and POSIX
> permissions only based only on filetype and DOS R/O attribute, as it has
> to on filesystems not supporting ACLs, like FAT/FAT32.
Got it.
It seems, Cygwin need a middle groung between these two for cases, where FS
support access control, but don't want to be mangled.
--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 28.08.2014, <17:22>
Sorry for my terrible english...
--
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