On Jun 24 21:51, Corinna Vinschen wrote:
> On Jun 24 18:07, Bill Zissimopoulos wrote:
> > Could my mapping of the NULL SID somehow interfere with Cygwin’s ACL
> > mapping? No way right? Turns out that: yes! File:winsup/cygwin/sec_acl.cc,
> > line:787
> 
> Read the comment at the beginning of the file explaining how new-style
> ACLs look like.
> 
> > Allow me to say that I find this a *gross* hack. You are subverting the
> > Windows ACL mechanism to store information that it was not designed to
> > store. I would love to hear a good rationale for this decision.
> 
> The usage of NULL SID ACEs to store special POSIX permission bits is
> long-standing behaviour, first implemented by U/Win and later adopted by
> Cygwin.  That older version is using Access-allowed NULL SID ACEs for
> *ages* to store ISVTX, ISGID and ISUID bits.  The new implementation
> uses access-denied NULL SID ACEs to store the same bits, plus the POSIX
> MASK bits.  Another access-denied NULL SID ACEs with the "Inherit Only"
> bit set is used to specify the same info for the POSIX default ACL.
> 
> > BTW, this also appears to break BashOnWindows: see [BASHW]
> 
> I'm not overly sympathetic.  Cygwin's implementation is older.  If
> Microsoft provides full support for POSIX permission bits plus POSIX
> ACLs including useful documentation, I'm willing to reconsider.  And
> matching patches are welcome of course.
> 
> What strikes me as weird is that nobody from the UoW side is trying
> to work with Cygwin ACLs or even trying to communicate with us to
> define and implement POSIX ACLs in a documented, generic way for both
> systems.

And why on earth does an access-denied NULL SID ACE affect SoW *at all*?


Corinna

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