POSIX permission mapping and NULL SIDs

POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

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

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

On Jun 24 21:51, Corinna Vinschen wrote:
> 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.

And why on earth does an access-denied NULL SID ACE affect SoW *at all*?


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

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

On 6/24/16, 12:51 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on
behalf of corinna-cygwin@cygwin.com> 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.

Thank you for the pointers and the historical information.

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

I also noticed that there is no uid mapping for nobody. On my OSX box it
is -2. On many other POSIX systems it appears to be the 32-bit or 16-bit
equivalent of -2.

For the time being I am mapping unknown SID’s to -1 as per Cygwin.

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

I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a
bad choice for some reason or other.

The main reason that I am weary of using an unused SID is that Microsoft
may decide to assign some special powers to it in a future release (e.g.
GodMode SID). But I agree that this is rather unlikely in the S-1-0-X
namespace.

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

I use the same SID for both nobody and nogroup. This should work as long
as you use the permission mapping from the [PERMS] document.

Bill

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

On Jun 24 21:37, Bill Zissimopoulos wrote:
> On 6/24/16, 12:51 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on
> behalf of corinna-cygwin@cygwin.com> wrote:
> >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.
> 
> I also noticed that there is no uid mapping for nobody. On my OSX box it
> is -2. On many other POSIX systems it appears to be the 32-bit or 16-bit
> equivalent of -2.

In fact it's an entirely arbitrary choice.  On Fedora Linux, for instance,
there is no "nogroup", but there is:

/etc/passwd:

  nobody:x:99:99:Nobody:/:/sbin/nologin
  nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

/etc/group:

  nobody:x:99:
  nfsnobody:x:65534:

Note the 65534 here.  This is -2 *if* the remote system uses 16 bit
signed uid/gid values.  However, these days uid/gid values are at least
32 bit, so -2 kind of lost its meaning.

> For the time being I am mapping unknown SID’s to -1 as per Cygwin.

We could kick this around a bit and maybe reserve -2, 99  or 65534 for
an arbitrary "nobody" account.  But since we're on Windows the SID value
is important, not so much the uid/gid values.

> >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?
> 
> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a
> bad choice for some reason or other.

I thought about Anonymous myself when I wrote my reply to your OP.  I
refrained from mentioning it because it might have some unexpected side
effect we're not aware about.

> The main reason that I am weary of using an unused SID is that Microsoft
> may decide to assign some special powers to it in a future release (e.g.
> GodMode SID). But I agree that this is rather unlikely in the S-1-0-X
> namespace.

I think it's very unlikely.  We could chose any RID value we like and
the chance for collision is nil.  When I created the new implementation
for POSIX ACLs, I toyed around with this already and used a special
Cygwin SID within the NULL SID AUTHORITY.  I'm not entirely sure why I
changed this to the NULL SID deny ACE.  I think I disliked the fact that
almost every Cygwin ACL would contain a mysterious "unknown SID".

On second thought, maybe that would have avoided the UoW problem?!?
Well, how should I have known about UoW when I implemanted this, right?

> >How do you differ nobody from nogroup if you use the same SID for both,
> >btw.?
> 
> I use the same SID for both nobody and nogroup. This should work as long
> as you use the permission mapping from the [PERMS] document.

Keep in mind that Interix only supported standard POSIX permission bits.
Cygwin strives to support POSIX ACLs per POSIX 1003.1e draft 17.  That's
a bit more extensive.


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

Re: POSIX permission mapping and NULL SIDs

[Erik Soderquist]

On Fri, Jun 24, 2016 at 5:59 PM, Corinna Vinschen wrote:
>> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a
>> bad choice for some reason or other.
>
> I thought about Anonymous myself when I wrote my reply to your OP.  I
> refrained from mentioning it because it might have some unexpected side
> effect we're not aware about.

I know in at least some versions of IIS, the Anonymous SID is the one
explicitly used for all not logged in www/ftp/etc clients connecting
to IIS -- not sure if that would affect this discussion.

-- Erik

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

On 6/24/16, 2:59 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
of corinna-cygwin@cygwin.com> wrote:


>>>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?
>> 
>> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a
>> bad choice for some reason or other.
>
>I thought about Anonymous myself when I wrote my reply to your OP.  I
>refrained from mentioning it because it might have some unexpected side
>effect we're not aware about.

Let me try this with the Anonymous SID and see what happens. In the
meantime I am going to ping some contacts from my MS days to see if there
are indeed unintended consequences.

>Keep in mind that Interix only supported standard POSIX permission bits.
>Cygwin strives to support POSIX ACLs per POSIX 1003.1e draft 17.  That's
>a bit more extensive.

Yes, that is beginning to dawn on me now that I have taken a better look
at sec_acl.cc.

Bill

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

On 6/24/16, 3:06 PM, "cygwin-owner@cygwin.com on behalf of Erik
Soderquist" <cygwin-owner@cygwin.com on behalf of
ErikSoderquist@gmail.com> wrote:


>On Fri, Jun 24, 2016 at 5:59 PM, Corinna Vinschen wrote:
>>> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is
>>>a
>>> bad choice for some reason or other.
>>
>> I thought about Anonymous myself when I wrote my reply to your OP.  I
>> refrained from mentioning it because it might have some unexpected side
>> effect we're not aware about.
>
>I know in at least some versions of IIS, the Anonymous SID is the one
>explicitly used for all not logged in www/ftp/etc clients connecting
>to IIS -- not sure if that would affect this discussion.

It is my understanding that this is the intended use of the Anonymous SID.
I have not thought enough to know whether it would fit properly in this
use case.

One caveat is that Cygwin already maps S-1-5-7 to uid 7. So does that mean
that 7==nobody in Cygwin’s case?

Bill

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

On 6/24/16, 3:53 PM, "cygwin-owner@cygwin.com on behalf of Bill
Zissimopoulos" <cygwin-owner@cygwin.com on behalf of
billziss@navimatics.com> wrote:


>One caveat is that Cygwin already maps S-1-5-7 to uid 7. So does that mean
>that 7==nobody in Cygwin’s case?

Here is output from Cygwin/SSHFS after mapping “nobody/nogroup” to S-1-5-7:
<<
billziss@windows:~$ cd /cygdrive/y
billziss@windows:/cygdrive/y$ ls -la
total 8
drwxr-xr-x 1 billziss ANONYMOUS LOGON  0 Jun 23 23:57 .
dr-xr-xr-x 1 billziss None             0 Jun 24 15:56 ..
-rw-r--r-- 1 billziss ANONYMOUS LOGON 15 Jun 23 23:57 Foo.txt
billziss@windows:/cygdrive/y$ cacls Foo.txt /S
Y:\Foo.txt 
"D:P(A;;0x1f019f;;;S-1-5-21-383059176-2062642591-2866287538-1001)(A;;FR;;;A
N)(A;;FR;;;WD)"

billziss@windows:/cygdrive/y$ ls -lna
total 8
drwxr-xr-x 1 197609      7  0 Jun 23 23:57 .
dr-xr-xr-x 1 197609 197121  0 Jun 24 15:58 ..
-rw-r--r-- 1 197609      7 15 Jun 23 23:57 Foo.txt
billziss@windows:/cygdrive/y$

>>


Opinions?

Bill

Re: POSIX permission mapping and NULL SIDs

[Brian Inglis]

> On Jun 24 21:37, Bill Zissimopoulos wrote:
>> On 6/24/16, 12:51 PM, "Corinna Vinschen" <cygwin-owner <at> cygwin.com on
>> behalf of corinna-cygwin <at> cygwin.com> wrote:
>> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a
>> bad choice for some reason or other.
> I thought about Anonymous myself when I wrote my reply to your OP.  I
> refrained from mentioning it because it might have some unexpected side
> effect we're not aware about.

http://www.hsc.fr/ressources/articles/win_net_srv/null_sessions_intro.html
indicates it is used for some MS RPC SMB named pipe services on IPC$ share
such as lsarpc, samr, browser and for XP and backward compatibility. 
Document has embedded refs and biblio at end. 


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

On 6/24/16, 2:59 PM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
of corinna-cygwin@cygwin.com> wrote:


>>>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?
>> 
>> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is a
>> bad choice for some reason or other.
>
>I thought about Anonymous myself when I wrote my reply to your OP.  I
>refrained from mentioning it because it might have some unexpected side
>effect we're not aware about.

I ended up implementing this a couple of days ago. I was just spending a
lazy Sunday morning and then it hit me: this is an exceptionally bad idea.

The problem is that Windows uses the Anonymous identity for accounts who
have not logged in using a password (as per Erik Soderquist’s email
regarding IIS behavior). Files in FUSE file systems that have a UID that
cannot be mapped to a SID, will suddenly be owned by that Anonymous user!

Obviously this is a huge security hole. I intend to fix this ASAP, but I
am now back to where we started. The obvious SID to use is the NULL SID,
but that is already used by Cygwin for other purposes.

>> The main reason that I am weary of using an unused SID is that Microsoft
>> may decide to assign some special powers to it in a future release (e.g.
>> GodMode SID). But I agree that this is rather unlikely in the S-1-0-X
>> namespace.
>
>I think it's very unlikely.  We could chose any RID value we like and
>the chance for collision is nil.  When I created the new implementation
>for POSIX ACLs, I toyed around with this already and used a special
>Cygwin SID within the NULL SID AUTHORITY.  I'm not entirely sure why I
>changed this to the NULL SID deny ACE.  I think I disliked the fact that
>almost every Cygwin ACL would contain a mysterious "unknown SID".

Ideally we should choose a SID that:

(1) Is very unlikely to be used by Microsoft at any point in the future.
(2) Cannot be associated to a user logon for any reason (see problem with
Anonymous SID) above.
(3) Maps to a reasonable UID in Cygwin.

I propose the following SID/UID mapping:

    S-1-0-99 <=> UID 0xffffffff (32-bit -1)

This is a SID in the S-1-0 (Null Authority) namespace (same one that
contains the NULL SID), which is unlikely to be used by Microsoft. So it
likely satisfies (1).

For the same reason (that it is a new/unused SID in the S-1-0) namespace,
I think it also satisfies (2).

If we follow the rules from Cygwin’s "POSIX accounts, permission, and
security” document [IDMAP], the SID S-1-0-99 maps to 0x10063. But we can
make a special rule for this SID to map it to a different UID. Mapping it
to -1 may be the easiest option, but perhaps we can also consider mapping
it to 0xfffffffe (-2).

Bill

[IDMAP] https://cygwin.com/cygwin-ug-net/ntsec.html

Re: POSIX permission mapping and NULL SIDs

[Andrey Repin]

Greetings, Bill Zissimopoulos!

>>> The main reason that I am weary of using an unused SID is that Microsoft
>>> may decide to assign some special powers to it in a future release (e.g.
>>> GodMode SID). But I agree that this is rather unlikely in the S-1-0-X
>>> namespace.
>>
>>I think it's very unlikely.  We could chose any RID value we like and
>>the chance for collision is nil.  When I created the new implementation
>>for POSIX ACLs, I toyed around with this already and used a special
>>Cygwin SID within the NULL SID AUTHORITY.  I'm not entirely sure why I
>>changed this to the NULL SID deny ACE.  I think I disliked the fact that
>>almost every Cygwin ACL would contain a mysterious "unknown SID".

> Ideally we should choose a SID that:

> (1) Is very unlikely to be used by Microsoft at any point in the future.
> (2) Cannot be associated to a user logon for any reason (see problem with
> Anonymous SID) above.
> (3) Maps to a reasonable UID in Cygwin.

> I propose the following SID/UID mapping:

>     S-1-0-99 <=> UID 0xffffffff (32-bit -1)

Why not S-1-0-65535 ? It'll map to 0x1FFFF then without any special rules.

> This is a SID in the S-1-0 (Null Authority) namespace (same one that
> contains the NULL SID), which is unlikely to be used by Microsoft. So it
> likely satisfies (1).

> For the same reason (that it is a new/unused SID in the S-1-0) namespace,
> I think it also satisfies (2).

> If we follow the rules from Cygwin’s "POSIX accounts, permission, and
> security” document [IDMAP], the SID S-1-0-99 maps to 0x10063. But we can
> make a special rule for this SID to map it to a different UID. Mapping it
> to -1 may be the easiest option, but perhaps we can also consider mapping
> it to 0xfffffffe (-2).

> Bill

> [IDMAP] https://cygwin.com/cygwin-ug-net/ntsec.html



-- 
With best regards,
Andrey Repin
Monday, June 27, 2016 12:08:13

Sorry for my terrible english...

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

On Jun 27 12:23, Andrey Repin wrote:
> Greetings, Bill Zissimopoulos!
> 
> >>> The main reason that I am weary of using an unused SID is that Microsoft
> >>> may decide to assign some special powers to it in a future release (e.g.
> >>> GodMode SID). But I agree that this is rather unlikely in the S-1-0-X
> >>> namespace.
> >>
> >>I think it's very unlikely.  We could chose any RID value we like and
> >>the chance for collision is nil.  When I created the new implementation
> >>for POSIX ACLs, I toyed around with this already and used a special
> >>Cygwin SID within the NULL SID AUTHORITY.  I'm not entirely sure why I
> >>changed this to the NULL SID deny ACE.  I think I disliked the fact that
> >>almost every Cygwin ACL would contain a mysterious "unknown SID".
> 
> > Ideally we should choose a SID that:
> 
> > (1) Is very unlikely to be used by Microsoft at any point in the future.
> > (2) Cannot be associated to a user logon for any reason (see problem with
> > Anonymous SID) above.
> > (3) Maps to a reasonable UID in Cygwin.
> 
> > I propose the following SID/UID mapping:
> 
> >     S-1-0-99 <=> UID 0xffffffff (32-bit -1)
> 
> Why not S-1-0-65535 ? It'll map to 0x1FFFF then without any special rules.

The exact value of the RID isn't overly important.  99 is just as well
as 65535.

As for the mapping, it would always have to be special cased.  The reason
is that LookupAccountSid would balk at this SID so we have to add extra
code to handle this SID anyway.

> > This is a SID in the S-1-0 (Null Authority) namespace (same one that
> > contains the NULL SID), which is unlikely to be used by Microsoft. So it
> > likely satisfies (1).
> 
> > For the same reason (that it is a new/unused SID in the S-1-0) namespace,
> > I think it also satisfies (2).
> 
> > If we follow the rules from Cygwin’s "POSIX accounts, permission, and
> > security” document [IDMAP], the SID S-1-0-99 maps to 0x10063. But we can
> > make a special rule for this SID to map it to a different UID. Mapping it
> > to -1 may be the easiest option, but perhaps we can also consider mapping
> > it to 0xfffffffe (-2).

Why don't we just follow Fedora Linux here and use a mapping to either
99 (nobody) or 65534 (nfsnobody)?  Both uid values are ununsed in the
mapping and 65534 aka 0xfffe has the additional advantage that it's not
mapped at all (all values between 0x1000 and 0xffff are invalid).

Also, since 65534 is -2 in a 16 bit uid it seems like a natural choice
to me.

So, what about S-1-0-65534 <-> 65534, name of "{nfs}nobody"?


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

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

On Jun 24 23:03, Bill Zissimopoulos wrote:
> On 6/24/16, 3:53 PM, "cygwin-owner@cygwin.com on behalf of Bill
> Zissimopoulos" <cygwin-owner@cygwin.com on behalf of
> billziss@navimatics.com> wrote:
> 
> 
> >One caveat is that Cygwin already maps S-1-5-7 to uid 7. So does that mean
> >that 7==nobody in Cygwin’s case?
> 
> Here is output from Cygwin/SSHFS after mapping “nobody/nogroup” to S-1-5-7:
> <<
> billziss@windows:~$ cd /cygdrive/y
> billziss@windows:/cygdrive/y$ ls -la
> total 8
> drwxr-xr-x 1 billziss ANONYMOUS LOGON  0 Jun 23 23:57 .
> dr-xr-xr-x 1 billziss None             0 Jun 24 15:56 ..
> -rw-r--r-- 1 billziss ANONYMOUS LOGON 15 Jun 23 23:57 Foo.txt
> billziss@windows:/cygdrive/y$ cacls Foo.txt /S
> Y:\Foo.txt 
> "D:P(A;;0x1f019f;;;S-1-5-21-383059176-2062642591-2866287538-1001)(A;;FR;;;A
> N)(A;;FR;;;WD)"
> 
> billziss@windows:/cygdrive/y$ ls -lna
> total 8
> drwxr-xr-x 1 197609      7  0 Jun 23 23:57 .
> dr-xr-xr-x 1 197609 197121  0 Jun 24 15:58 ..
> -rw-r--r-- 1 197609      7 15 Jun 23 23:57 Foo.txt
> billziss@windows:/cygdrive/y$
> 
> >>
> 
> 
> Opinions?

Let's better not use anonymous.  It could be a security risk.  It might
not do harm, but it also might give unwanted access rights in some
scenarios.


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

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

>Why don't we just follow Fedora Linux here and use a mapping to either
>99 (nobody) or 65534 (nfsnobody)?  Both uid values are ununsed in the
>mapping and 65534 aka 0xfffe has the additional advantage that it's not
>mapped at all (all values between 0x1000 and 0xffff are invalid).
>
>Also, since 65534 is -2 in a 16 bit uid it seems like a natural choice
>to me.
>
>So, what about S-1-0-65534 <-> 65534, name of "{nfs}nobody"?

I am happy with the S-1-0-65534 *SID*, but I note that the 65534 *UID* is
perhaps *not* a good choice. It is actually already mapped to
S-1-5-15-4095, according to your own [IDMAP] document:

S-1-5-X-RID                          <=> uid/gid: 0x1000 * X + RID

With X=15 and RID=4095, we get uid==65534. Unfortunately S-1-5-15 is the
SID for "This Organization” according to the “Well-known security
identifiers in Windows operating systems” document [WKSID]. OTOH, because
S-1-5-15 is a “leaf” SID and not a “namespace” it may be possible to
assume that the S-1-5-15-4095 SID cannot appear (I am not sure about that).


BTW, I have here a partitioning of the UID namespace that may help choose
the right mapping:

/*
 * UID namespace partitioning (from [IDMAP] rules):
 *
 * 0x000000 + RID              S-1-5-RID,S-1-5-32-RID
 * 0x000ffe                    OtherSession
 * 0x000fff                    CurrentSession
 * 0x001000 * X + RID          S-1-5-X-RID ([WKSID]:
X=1-15,17-21,32,64,80,83)
 * 0x010000 + 0x100 * X + Y    S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16)
 * 0x030000 + RID              S-1-5-21-X-Y-Z-RID
 * 0x060000 + RID              S-1-16-RID
 * 0x100000 + RID              S-1-5-21-X-Y-Z-RID
 */


Clearly the namespace is very busy with multiple overlapping ranges.

With all that and to help conclude this thread I gather here all the
proposed mappings. Corinna, I will use the one which you prefer the most:

S-1-0-65534                    <-> 65534

S-1-0-65534                    <-> -1==0xffffffff
S-1-0-65534                    <-> -2==0xfffffffe

S-1-0-99                       <-> -1==0xffffffff
S-1-0-99                       <-> -2==0xfffffffe


Bill


[IDMAP] https://cygwin.com/cygwin-ug-net/ntsec.html
[WKSID] https://support.microsoft.com/en-us/kb/243330

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

On Jun 27 19:01, Bill Zissimopoulos wrote:
> 
> >Why don't we just follow Fedora Linux here and use a mapping to either
> >99 (nobody) or 65534 (nfsnobody)?  Both uid values are ununsed in the
> >mapping and 65534 aka 0xfffe has the additional advantage that it's not
> >mapped at all (all values between 0x1000 and 0xffff are invalid).
> >
> >Also, since 65534 is -2 in a 16 bit uid it seems like a natural choice
> >to me.
> >
> >So, what about S-1-0-65534 <-> 65534, name of "{nfs}nobody"?
> 
> I am happy with the S-1-0-65534 *SID*, but I note that the 65534 *UID* is
> perhaps *not* a good choice. It is actually already mapped to
> S-1-5-15-4095, according to your own [IDMAP] document:
> 
> S-1-5-X-RID                          <=> uid/gid: 0x1000 * X + RID
> 
> With X=15 and RID=4095, we get uid==65534.

This doesn't make any sense.  This is an entirely artificial example of
how one can construct arbitrary SIDs.

> Unfortunately S-1-5-15 is the
> SID for "This Organization” according to the “Well-known security
> identifiers in Windows operating systems” document [WKSID]. OTOH, because
> S-1-5-15 is a “leaf” SID and not a “namespace” it may be possible to
> assume that the S-1-5-15-4095 SID cannot appear (I am not sure about that).

There is no such SID and there never will be.

Ok.  Please keep in mind that

a) there can't be a bijective mapping between arbitrary length SIDs
   and a 32 bit uid/gid.

b) The mapping used in Cygwin is not self-created but (mostly, except
   for a single deviation) identical to the Interix mapping.  The code
   basically follows how this mapping has been defined by Microsoft.

> BTW, I have here a partitioning of the UID namespace that may help choose
> the right mapping:
> 
> /*
>  * UID namespace partitioning (from [IDMAP] rules):
>  *
>  * 0x000000 + RID              S-1-5-RID,S-1-5-32-RID
>  * 0x000ffe                    OtherSession
>  * 0x000fff                    CurrentSession
>  * 0x001000 * X + RID          S-1-5-X-RID ([WKSID]:
> X=1-15,17-21,32,64,80,83)
>  * 0x010000 + 0x100 * X + Y    S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16)
>  * 0x030000 + RID              S-1-5-21-X-Y-Z-RID
>  * 0x060000 + RID              S-1-16-RID
>  * 0x100000 + RID              S-1-5-21-X-Y-Z-RID
>  */

You're aware that I wrote the code for this mapping as well as its
documentation? :)

> Clearly the namespace is very busy with multiple overlapping ranges.

The overlapping is much alleviated by the fact that only certain SIDs
can exist, plus the fact that AD admins can choose an offset value for
AD accounts of various domains.  Search for "trustPosixOffset" in
https://cygwin.com/cygwin-ug-net/ntsec.html.

> With all that and to help conclude this thread I gather here all the
> proposed mappings. Corinna, I will use the one which you prefer the most:
> 
> S-1-0-65534                    <-> 65534

This one is still my favorite.  Again, the range from 0x1000 up to
0xffff is unused.  Right now any incoming uid/gid value in this range
for a reverse SID lookup is treated as invalid SID.


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

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

On 6/28/16, 3:27 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
of corinna-cygwin@cygwin.com> wrote:


>>Ok.  Please keep in mind that
>
>a) there can't be a bijective mapping between arbitrary length SIDs
>   and a 32 bit uid/gid.
>
>b) The mapping used in Cygwin is not self-created but (mostly, except
>   for a single deviation) identical to the Interix mapping.  The code
>   basically follows how this mapping has been defined by Microsoft.

Corinna, please stop explaining things to me that I already know.

>> BTW, I have here a partitioning of the UID namespace that may help
>>choose
>> the right mapping:
>> 
>> /*
>>  * UID namespace partitioning (from [IDMAP] rules):
>>  *
>>  * 0x000000 + RID              S-1-5-RID,S-1-5-32-RID
>>  * 0x000ffe                    OtherSession
>>  * 0x000fff                    CurrentSession
>>  * 0x001000 * X + RID          S-1-5-X-RID ([WKSID]:
>> X=1-15,17-21,32,64,80,83)
>>  * 0x010000 + 0x100 * X + Y    S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16)
>>  * 0x030000 + RID              S-1-5-21-X-Y-Z-RID
>>  * 0x060000 + RID              S-1-16-RID
>>  * 0x100000 + RID              S-1-5-21-X-Y-Z-RID
>>  */
>
>You're aware that I wrote the code for this mapping as well as its
>documentation? :)

Corinna, of course I am aware of that. I have found your original post to
this list about it. Why would you think otherwise? And why would it change
anything?

>>With all that and to help conclude this thread I gather here all the
>> proposed mappings. Corinna, I will use the one which you prefer the
>>most:
>> 
>> S-1-0-65534                    <-> 65534
>
>This one is still my favorite.  Again, the range from 0x1000 up to
>0xffff is unused.  Right now any incoming uid/gid value in this range
>for a reverse SID lookup is treated as invalid SID.

I disagree. You are saying that it is unused, but a (perhaps erroneous)
SID would map into that space.

In any case I will use your mapping of S-1-0-65534 <-> 65534.

Bill

Re: POSIX permission mapping and NULL SIDs

[John Ruckstuhl]

Since these emails go to a list, not just Bill, and are archived,
the extra detail is added value and appreciated by other people now & in future.

On Tue, Jun 28, 2016 at 11:06 AM, Bill Zissimopoulos
<billziss@navimatics.com> wrote:
> On 6/28/16, 3:27 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
> of corinna-cygwin@cygwin.com> wrote:
>
>
>>>Ok.  Please keep in mind that
>>
>>a) there can't be a bijective mapping between arbitrary length SIDs
>>   and a 32 bit uid/gid.
>>
>>b) The mapping used in Cygwin is not self-created but (mostly, except
>>   for a single deviation) identical to the Interix mapping.  The code
>>   basically follows how this mapping has been defined by Microsoft.
>
> Corinna, please stop explaining things to me that I already know.
>
>>> BTW, I have here a partitioning of the UID namespace that may help
>>>choose
>>> the right mapping:
>>>
>>> /*
>>>  * UID namespace partitioning (from [IDMAP] rules):
>>>  *
>>>  * 0x000000 + RID              S-1-5-RID,S-1-5-32-RID
>>>  * 0x000ffe                    OtherSession
>>>  * 0x000fff                    CurrentSession
>>>  * 0x001000 * X + RID          S-1-5-X-RID ([WKSID]:
>>> X=1-15,17-21,32,64,80,83)
>>>  * 0x010000 + 0x100 * X + Y    S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16)
>>>  * 0x030000 + RID              S-1-5-21-X-Y-Z-RID
>>>  * 0x060000 + RID              S-1-16-RID
>>>  * 0x100000 + RID              S-1-5-21-X-Y-Z-RID
>>>  */
>>
>>You're aware that I wrote the code for this mapping as well as its
>>documentation? :)
>
> Corinna, of course I am aware of that. I have found your original post to
> this list about it. Why would you think otherwise? And why would it change
> anything?
>
>>>With all that and to help conclude this thread I gather here all the
>>> proposed mappings. Corinna, I will use the one which you prefer the
>>>most:
>>>
>>> S-1-0-65534                    <-> 65534
>>
>>This one is still my favorite.  Again, the range from 0x1000 up to
>>0xffff is unused.  Right now any incoming uid/gid value in this range
>>for a reverse SID lookup is treated as invalid SID.
>
> I disagree. You are saying that it is unused, but a (perhaps erroneous)
> SID would map into that space.
>
> In any case I will use your mapping of S-1-0-65534 <-> 65534.
>
> Bill
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

On Jun 28 18:06, Bill Zissimopoulos wrote:
> On 6/28/16, 3:27 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
> of corinna-cygwin@cygwin.com> wrote:
> 
> 
> >>Ok.  Please keep in mind that
> >
> >a) there can't be a bijective mapping between arbitrary length SIDs
> >   and a 32 bit uid/gid.
> >
> >b) The mapping used in Cygwin is not self-created but (mostly, except
> >   for a single deviation) identical to the Interix mapping.  The code
> >   basically follows how this mapping has been defined by Microsoft.
> 
> Corinna, please stop explaining things to me that I already know.

Sorry but I don't grok this.  During this discussion you were explaining
things to me which I obviously had to know.  If I'm explainig things to
you you already know, well, sorry about that.  Your attempt at creating
an artificial SID just to prove that a collision could be constructed
looked like you didn't understand how well-known Windows SIDs work and
are constructed, and that there's no way for a collision from a valid
Windows SID here.

> >> BTW, I have here a partitioning of the UID namespace that may help
> >>choose
> >> the right mapping:
> >> 
> >> /*
> >>  * UID namespace partitioning (from [IDMAP] rules):
> >>  *
> >>  * 0x000000 + RID              S-1-5-RID,S-1-5-32-RID
> >>  * 0x000ffe                    OtherSession
> >>  * 0x000fff                    CurrentSession
> >>  * 0x001000 * X + RID          S-1-5-X-RID ([WKSID]:
> >> X=1-15,17-21,32,64,80,83)
> >>  * 0x010000 + 0x100 * X + Y    S-1-X-Y ([WKSID]: X=1,2,3,4,5,9,16)
> >>  * 0x030000 + RID              S-1-5-21-X-Y-Z-RID
> >>  * 0x060000 + RID              S-1-16-RID
> >>  * 0x100000 + RID              S-1-5-21-X-Y-Z-RID
> >>  */
> >
> >You're aware that I wrote the code for this mapping as well as its
> >documentation? :)
> 
> Corinna, of course I am aware of that. I have found your original post to
> this list about it. Why would you think otherwise? And why would it change
> anything?

If that's the case, then why do you explain all these things to me?  I'm
a bit at a loss to see the difference between me explaining things to
you you already know vs. you explaing things to me I already know.
Aren't we kind of on par here?

But, never mind.

> >>With all that and to help conclude this thread I gather here all the
> >> proposed mappings. Corinna, I will use the one which you prefer the
> >>most:
> >> 
> >> S-1-0-65534                    <-> 65534
> >
> >This one is still my favorite.  Again, the range from 0x1000 up to
> >0xffff is unused.  Right now any incoming uid/gid value in this range
> >for a reverse SID lookup is treated as invalid SID.
> 
> I disagree. You are saying that it is unused, but a (perhaps erroneous)
> SID would map into that space.

Yes that's possible.  However, where would this erroneous SID come from?

The chances that a SID comes in which gets converted to uid/gid 0xfffffffe
is actually higher.  See UNIX_POSIX_OFFSET.

> In any case I will use your mapping of S-1-0-65534 <-> 65534.

Thanks.  Do you want to add handling for this mapping to
pwdgrp::fetch_account_from_windows yourself or shall I do it?  I could
come up with a patch in the next couple of days.  I will prepare a
developer's snapshot then, so you can immediately test if it works as
desired.


Thanks again,
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 --]

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

Hi Bill,

On Jun 29 10:21, Corinna Vinschen wrote:
> On Jun 28 18:06, Bill Zissimopoulos wrote:
> > In any case I will use your mapping of S-1-0-65534 <-> 65534.
> 
> Thanks.  Do you want to add handling for this mapping to
> pwdgrp::fetch_account_from_windows yourself or shall I do it?  I could
> come up with a patch in the next couple of days.  I will prepare a
> developer's snapshot then, so you can immediately test if it works as
> desired.

How do we avoid name collisions?  I can easily see admins creating an
AD account called "nobody".

Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"?


Thanks,
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 --]

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

[-- Attachment #1.1: Type: text/plain, Size: 904 bytes --]

On Jun 29 15:45, Corinna Vinschen wrote:
> Hi Bill,
> 
> On Jun 29 10:21, Corinna Vinschen wrote:
> > On Jun 28 18:06, Bill Zissimopoulos wrote:
> > > In any case I will use your mapping of S-1-0-65534 <-> 65534.
> > 
> > Thanks.  Do you want to add handling for this mapping to
> > pwdgrp::fetch_account_from_windows yourself or shall I do it?  I could
> > come up with a patch in the next couple of days.  I will prepare a
> > developer's snapshot then, so you can immediately test if it works as
> > desired.
> 
> How do we avoid name collisions?  I can easily see admins creating an
> AD account called "nobody".
> 
> Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"?

Preliminary patch attached.


Corinna

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

[-- Attachment #1.2: 0001-Handle-WinFSP-nobody-account.patch --]
[-- Type: text/plain, Size: 2102 bytes --]

From a0bdba1cc4b8515e933e1c1caf59fcc310c48613 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <corinna@vinschen.de>
Date: Wed, 29 Jun 2016 17:12:38 +0200
Subject: [PATCH] Handle WinFSP nobody account

Per discussion started at
https://cygwin.com/ml/cygwin/2016-06/msg00347.html

S-1-0-65534 == WinFSP\nobody == WinFSP+nobody == uid/gid 65534
---
 winsup/cygwin/uinfo.cc | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 247131d..af1a4e5 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -1894,6 +1894,14 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap)
 	}
       if (!ret)
 	{
+	  if (!strcmp (arg.name, "WinFSP+nobody"))
+	    {
+	      /* Special case "nobody" for reproducible construction of a
+		 nobody SID for WinFSP.  We use the value 65534 which is
+		 -2 with 16 bit uid/gids. */
+	      csid.create (0, 1, 0xfffe);
+	      break;
+	    }
 	  debug_printf ("LookupAccountNameW (%W), %E", name);
 	  return NULL;
 	}
@@ -2004,6 +2012,15 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap)
 	  sid = logon_sid;
 	  break;
 	}
+      else if (arg.id == 0xfffe)
+	{
+	  /* Special case "nobody" for reproducible construction of a
+	     nobody SID for WinFSP.  We use the value 65534 which is
+	     -2 with 16 bit uid/gids. */
+	  csid.create (0, 1, 0xfffe);
+	  sid = csid;
+	  break;
+	}
       else if (arg.id < 0x10000)
 	{
 	  /* Nothing. */
@@ -2428,6 +2445,14 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap)
 	  return NULL;
 	}
     } 
+  else if (sid_id_auth (sid) == 0 && sid_sub_auth (sid, 0) == 0xfffe)
+    {
+      uid = gid = 0xfffe;
+      wcpcpy (dom, L"WinFSP");
+      wcpcpy (name = namebuf, L"nobody");
+      fully_qualified_name = true;
+      acc_type = SidTypeUnknown;
+    }
   else if (sid_id_auth (sid) == 5 /* SECURITY_NT_AUTHORITY */
 	   && sid_sub_auth (sid, 0) == SECURITY_LOGON_IDS_RID)
     {
-- 
2.5.5


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

Re: POSIX permission mapping and NULL SIDs

[Bill Zissimopoulos]

On 6/29/16, 1:21 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
of corinna-cygwin@cygwin.com> wrote:


>If that's the case, then why do you explain all these things to me?  I'm
>a bit at a loss to see the difference between me explaining things to
>you you already know vs. you explaing things to me I already know.
>Aren't we kind of on par here?

Yes, we are.

Perhaps I spoke “out of turn” as the Americans say. I am sorry if it also
felt like I was explaining things that you know.

>>In any case I will use your mapping of S-1-0-65534 <-> 65534.
>
>Thanks.  Do you want to add handling for this mapping to
>pwdgrp::fetch_account_from_windows yourself or shall I do it?  I could
>come up with a patch in the next couple of days.  I will prepare a
>developer's snapshot then, so you can immediately test if it works as
>desired.

I have already added the mapping to WinFsp-FUSE. I can look into what is
required to patch Cygwin.

>>How do we avoid name collisions?  I can easily see admins creating an
>>AD account called "nobody".
>>Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"?
>
>Preliminary patch attached.

Ok, looks like you have patched it already. Thanks for this.

BTW, if the name is case-sensitive (strcmp) I usually use the “WinFsp”
capitalization, if it makes a difference.

Also do you foresee any situation where the “nobody” mapping might be
useful outside of WinFsp? Perhaps it would make more sense to name it
“nodomain+nobody”? Just a suggestion.

Many thanks.

Bill

Re: POSIX permission mapping and NULL SIDs

[Corinna Vinschen]

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

On Jun 30 00:03, Bill Zissimopoulos wrote:
> On 6/29/16, 1:21 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
> of corinna-cygwin@cygwin.com> wrote:
> >>How do we avoid name collisions?  I can easily see admins creating an
> >>AD account called "nobody".
> >>Shall we fake a "WinFSP" domain such that the name is "WinFSP+nobody"?
> >
> >Preliminary patch attached.
> 
> Ok, looks like you have patched it already. Thanks for this.
> 
> BTW, if the name is case-sensitive (strcmp) I usually use the “WinFsp”
> capitalization, if it makes a difference.

It shouldn't, but of course I'd fix that to use your capitalization.
After all it's your project :)

> Also do you foresee any situation where the “nobody” mapping might be
> useful outside of WinFsp? Perhaps it would make more sense to name it
> “nodomain+nobody”? Just a suggestion.

Hmm, yes, maybe.  Funny idea:  "no+body" :)


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