This is the mail archive of the
cygwin
mailing list for the Cygwin project.
POSIX permission mapping and NULL SIDs
- From: Bill Zissimopoulos <billziss at navimatics dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Fri, 24 Jun 2016 18:07:20 +0000
- Subject: POSIX permission mapping and NULL SIDs
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp dot mailfrom=billziss at navimatics dot com;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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