POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos <billziss@navimatics.com>]

EXEUTIVE EDITION

I am seeking information on how exactly Cygwin uses NULL SID ACE’s in
Windows ACL’s. Cygwin’s use of NULL SID ACE’s interferes with my use of
the NULL SID to represent “nobody”/“nogroup”.


AN EXPERIMENT

Working through some remaining warts in my WinFsp-FUSE for Cygwin layer I
stumbled upon an interesting one last night. In one Cygwin window I ran
    sshfs -d -o idmap=user XXXX@XXXX Y:

Then in another:
    billziss@windows:~$ cd /cygdrive/y
    billziss@windows:/cygdrive/y$ ls -la
    total 8
    drwxr-xr-t 1 billziss Unknown+Group  0 Jun 23 23:57 .
    dr-xr-xr-x 1 billziss None           0 Jun 24 10:13 ..
    -rw-r--r-T 1 billziss Unknown+Group 15 Jun 23 23:57 Foo.txt


What are those sticky bits doing there?!
    billziss@windows:/cygdrive/y$ cacls Foo.txt /S
    Y:\Foo.txt 
"D:P(A;;0x1f019f;;;S-1-5-21-XXXX-1001)(A;;FR;;;S-1-0-0)(A;;FR;;;WD)"


Ok, so WinFsp-FUSE presents an ACL with the proper rights for the owner
(billziss), read rights for the NULL SID and read rights for the WORLD
SID. We see the NULL SID because WinFsp-FUSE maps unknown users to it
(nobody/nogroup).

This looks correct. How does Cygwin decide that the sticky bit is somehow
set?!


PERMISSION MAPPING IN WINFSP-FUSE

WinFsp-FUSE implements permissions as described in the "Permissions In
Microsoft Services for UNIX v3.0” [PERMS]. This document contains a
discussion of mapping the sticky and setuid/setgid bits. They use
combinations of the FILE_DELETE_CHILD access right to implement the sticky
bit and NTFS extended attributes to implement the setuid/setgid bits.
WinFsp-FUSE follows the same methodology for the sticky bit and ignores
the setuid/setgid bits.

WinFsp-FUSE also has a UID/SID mapping that is (mostly) compatible with
Cygwin’s. I do not implement the trustPosixOffset, because I am lazy and
because I do not understand it. Turns out that there is another
incompatibility: I map unknown UID’s to the NULL SID (S-1-0-0).

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

    if (ace_sid == well_known_null_sid)
    {
        /* Fetch special bits. */
        attr |= CYG_ACE_ISBITS_TO_POSIX (ace->Mask);
        if (ace->Header.AceType == ACCESS_DENIED_ACE_TYPE
            && ace->Mask & CYG_ACE_NEW_STYLE)
        {
            /* New-style ACL.  Note the fact that a mask value is present
               since that changes how getace fetches the information.
That's
               fine, because the NULL deny ACE is supposed to precede all
               USER, GROUP and GROUP_OBJ entries.  Any ACL not created that
               way has been rearranged by the Windows functionality to
create
               the brain-dead "canonical" ACL order and is broken anyway.
*/
            new_style = true;
            attr |= CYG_ACE_ISBITS_TO_POSIX (ace->Mask);

So Cygwin appears to use NULL SID ACE’s to store the special bits. In
addition if the ACE is a special ACCESS_DENIED one it assigns even more
semantics to it.


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.


BTW, this also appears to break BashOnWindows: see [BASHW]

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

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

Bill

[PERMS] https://technet.microsoft.com/en-us/library/bb463216.aspx
[BASHW] https://github.com/Microsoft/BashOnWindows/issues/51
[OPOST] https://www.cygwin.com/ml/cygwin/2015-02/msg00197.html