public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: POSIX permission mapping and NULL SIDs
Date: Tue, 28 Jun 2016 11:08:00 -0000	[thread overview]
Message-ID: <20160628102705.GA22797@calimero.vinschen.de> (raw)
In-Reply-To: <D396C16E.9770%billziss@navimatics.com>

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

  reply	other threads:[~2016-06-28 10:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 19:02 Bill Zissimopoulos
2016-06-24 21:37 ` Corinna Vinschen
2016-06-24 22:00   ` Corinna Vinschen
2016-06-24 22:06   ` Bill Zissimopoulos
2016-06-24 22:31     ` Corinna Vinschen
2016-06-24 22:36       ` Erik Soderquist
2016-06-24 23:03         ` Bill Zissimopoulos
2016-06-24 23:51           ` Bill Zissimopoulos
2016-06-27 13:20             ` Corinna Vinschen
2016-06-24 22:53       ` Bill Zissimopoulos
2016-06-25 17:10       ` Brian Inglis
2016-06-27 10:26       ` Bill Zissimopoulos
2016-06-27 10:29         ` Andrey Repin
2016-06-27 12:06           ` Corinna Vinschen
2016-06-27 20:31             ` Bill Zissimopoulos
2016-06-28 11:08               ` Corinna Vinschen [this message]
2016-06-28 19:17                 ` Bill Zissimopoulos
2016-06-28 19:17                   ` John Ruckstuhl
2016-06-29  8:43                   ` Corinna Vinschen
2016-06-29 15:14                     ` Corinna Vinschen
2016-06-29 16:06                       ` Corinna Vinschen
2016-06-30  9:26                     ` Bill Zissimopoulos
2016-06-30 14:15                       ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160628102705.GA22797@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).