This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

POSIX permission mapping and NULL SIDs


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


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

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

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


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/,

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]