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