Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

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.

> In any case I am seeking more information regarding Cygwin’s use of NULL
> SID’s. I have found an old post that sheds some light [OPOST].

That's old.  See the comment at the beginning of sec_acl.cc, as well as
the comments in set_posix_access() in the same file.

> I am also seeking an alternative to using the NULL SID for
> “nobody”/“nogroup”. Is there a Cygwin suggested one?

Not yet.  We're coming from the other side.  We always have *some* SID.
pwdgrp::fetch_account_from_windows() in uinfo.cc tries to convert the SID
to a passwd or group entry.  If everything fails, the SID is used in this
passwd/group entry verbatim, but mapped to uid/gid -1.

If you want some specific mapping we can arrange that, but it must not
be the NULL SID.  If you know you're communicating with a Cygwin process,
what about using an arbitrary, unused SID like S-1-0-42?

How do you differ nobody from nogroup if you use the same SID for both,
btw.?


Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]