This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.18
- From: random user <cnpxzsdwle4m0dkt at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 13 Jan 2016 12:48:07 -0800
- Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.18
- Authentication-results: sourceware.org; auth=none
- References: <announce dot 20160111193913 dot GB2832 at calimero dot vinschen dot de> <5695EC0F dot 7010103 at gmail dot com> <20160113151249 dot GM15034 at calimero dot vinschen dot de>
>> It's a bit late now to change how Cygwin constructs and evaluates ACLs.
Sorry, with the holidays and other issues it wasn't possible for me to
look at the test drops earlier.
Going production with a new Cygwin NTFS ACL layout incompatible with
NTFS-3g's already-existing layout would seem a long-term decision
regarding Cygwin <-> Linux interoperability. Please consider.
On 01/13/2016 07:12 AM, Corinna Vinschen wrote:
> On Jan 12 22:17, random user wrote:
>> Something I wasn't aware of at the time of our prior discussion is
>> that the Linux NTFS-3g driver already supports Linux extended ACLs
>> on NTFS. This is discussed at
>> I explored taking a flash card back and forth between Cygwin
>> 2.4.0-0.18 and a Linux system, testing how each interprets what the
>> other wrote.
>> I find they don't seem to interpret each other's per-group and mask
>> permission bits correctly when creating their Posix interpretation of
>> an NTFS ACL.
>> I also find that somehow setting extended ACLs on Linux for a
>> directory is causing Cygwin to then see that object as a socket, if
>> I'm reading the below correctly. 'ls' on Cygwin won't descend into
>> that as it normally would for a directory,
>> bash: cd: dir_acl: Not a directory
>> results when attempting to cd into it, etc.
>> I don't know how common such uses are, but I do use both Cygwin and
>> Linux on the same flash cards and external disks. If they are both
>> going to support Posix-style extended ACLs written to NTFS, it'd seem
>> nice if they could do so in compatible ways.
> Cygwin is trying to create an ACL with least possible entries while at
> the same time being POSIX compatible. Apart from the NULL SID deny ACE
> to keep mask info and special bits, it's a pretty normal ACL.
> It's a bit late now to change how Cygwin constructs and evaluates ACLs.
> I'll take a look into the dir vs. socket thingy, but no guarantee that
> I can change that for 2.4.0.
>> bash 1 34 # ls -al
>> total 0
>> drwx------+ 1 sally sally 0 Jan 12 20:42 .
>> drwx------+ 1 sally sally 0 Jan 12 20:40 ..
>> srwxr-----+ 1 sally sally 0 Jan 12 20:42 dir_acl
>> -rwxr-----+ 1 sally sally 0 Jan 12 20:42 file_acl
>> -rw------- 1 sally sally 0 Jan 12 20:41 file_simple
> Weird. The only way to set the filetype to socket is if the file is a
> Cygwin symlink (file with system DOS bit set and starting with the
> string "!<socket >".
>> bash 1 41 # getfacl dir_acl
>> # file: dir_acl
>> # owner: sally
>> # group: sally
>> bash 1 42 # icacls dir_acl
>> dir_acl CYGWIN\julia_ug:(NP)(DENY)(W,Rc,WO,X,DC)
> It will be hard to reproduce such an ACL. It's just as non-standard as
> a Cygwin ACL, just differently so. What bugs me is the deny ACE for
> sally_ug which looks pretty weird to me.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple