DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-id:content-transfer-encoding:mime-version; q=dns; s=
	default; b=yS3fokts64Rk0971haTAwQY+n5HkKtlOBtU/z1qXxmz7SMu6DaJmT
	7RjWYrTkmEdgg/+ocjH9DE+HbhXXi2PsRlH9g6e/vuot7nZDZjpq+VYznYtcI99y
	FfbVKpaIFbCYeKYDQJbnRxJ7L62EM9FX5z9Hxfr1/+GcjCZLHfcoyM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: Bill Zissimopoulos <billziss AT navimatics DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: POSIX permission mapping and NULL SIDs
Date: Fri, 24 Jun 2016 18:07:20 +0000
Message-ID: <D392BA70.95D4%billziss@navimatics.com>
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-office365-filtering-correlation-id: d5b0a6d5-316d-496a-b01a-08d39c5a62f3
x-microsoft-exchange-diagnostics: 1;CY1PR07MB2200;6:nLhINNGQCidFz3y2wQ/C+30QBkYtOECTJ5OJMsGDJrJT+p71klcae5xfvt7Z8t9OTaVqxB/GKWbSriFjVVqbXb0PRLNxZYTZZSDNkLnIDj++5jUFwRRc+66NSguJiYgMc5osFWtSJqqj7/YPQMGnQUi4Z6yUvhxozPrMbKXf/brWCQTeoBUkbe1kuNck3sAtKJVtL3ylHbnQcoKtFUaMmzbLVNPRxTWlh2UGReuHS/3Qt1I6av5Edh6C/Xqb8HoAG3t+hl7JFL76N+TgPmYnQ1wLvH9c/ZDK2rm50yAtXT1gxwXT4N254mHo4Mm4Ioz19neKftC3KSWYxHZrZletsQ==;5:+E5PPh9kIDv5tXtRxRj6e1+SSqWj8WeDcNMrpMB4YQRyN1AsVeu8KO3v7ZL9OTjz02WQ7OO3JuEYaRKMB120LVvn5JsUZhf5fUx1RsJIwA6kWPq35GC0SXKUsMx/DFC3MMitMyLiiPbZd221mMf/SA==;24:0CzpUezk/unOSmaQIzC8SqbusvOR1MCqIRgckU1Q55h7lDYDtuZIDfsJBzIhdJE8T/RUah/YdIoBQ/DyHiLv0/XL5n21kSV9/MHSe7l9Zxg=;7:DiZRedv7vE24QxqLZnY4hOGQlyV2hl1d5DkRlqnXz89h0nCXxx4IsMkfBIqGgM7PijDKrKOp3zJBONld8glRviSc88X4NTyBdBXt+NOjwXldon92oAAArcTqOg+Dv4S/sowypOihO8DV2ewlIhUWC8ve3wpWY09ycCQu21rUWQ7bgLVCj0OZVWcPFtZCulZ2s3TllJYujkRfxSR6ZTDhatlu45lhTYyZx6CZe7aEHCkd95S/1t9RoQbKJFepYoZ936GAo+DHrWvYKEVaJ2iDFA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2200;
x-microsoft-antispam-prvs: <CY1PR07MB2200E36276837C5F6843A265BC2E0 AT CY1PR07MB2200 DOT namprd07 DOT prod DOT outlook DOT com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(268704632989789);
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:CY1PR07MB2200;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2200;
x-forefront-prvs: 0983EAD6B2
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(3905003)(199003)(189002)(305945005)(106356001)(229853001)(2351001)(586003)(97736004)(106116001)(110136002)(107886002)(99286002)(189998001)(92566002)(102836003)(6116002)(3846002)(7736002)(81166006)(8676002)(66066001)(1730700003)(2501003)(8936002)(68736007)(105586002)(81156014)(11100500001)(10400500002)(77096005)(2906002)(19580405001)(19580395003)(15975445007)(3280700002)(5002640100001)(87936001)(2900100001)(122556002)(3660700001)(50986999)(54356999)(86362001)(5640700001)(36756003)(101416001)(7846002)(450100001)(94096001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR07MB2200;H:CY1PR07MB2199.namprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
received-spf: None (protection.outlook.com: navimatics.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <CA8F8317314A9141A1E4DAC572C04293 AT namprd07 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
X-OriginatorOrg: navimatics.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2016 18:07:20.2432 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 21071be9-4f9a-413b-89ac-8353a5d2410a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2200
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id u5OI7lSl015899

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 AT XXXX Y:

Then in another:
    billziss AT windows:~$ cd /cygdrive/y
    billziss AT 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 AT 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