X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=rAAkU4j+Yro0eUZjR1rnzWtTFzus70Lamjhd/RJq5UyLcdPt438L6
	qXNpKUg3kw+KKUOWl6SYUcM3ZLun1U84ZeqC55MRjU9b7bSA/DI3gjJhRpYFkcpZ
	sS/3e34kIaebHUpjvB7wHUlfH2ytZ36meMHa3rZXx1Gvxj7VVSZIbk=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=WNbC9nO4mtGyr6cbLEYtcGM9RX8=; b=oi5qwjwERKORY5jKACrN+885cR4s
	KmUqAoGtaePeazxvEbJ6y8yzo7G+/r7AMsRBT03k6gRestBSYy3kcXF2ak6G5NGE
	u+L7yuKX8P83CPACcxM4NJfxDml0oT81pL5R5TXusZvOtBmSVeFDS2/mieRutnXz
	EQ8E7OP1ZluLnBw=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-96.3 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=Hx-languages-length:3048, H*MI:D396C16E.9770, H*i:D396C16E.9770, H*f:D396C16E.9770
X-HELO:	calimero.vinschen.de
Date:	Tue, 28 Jun 2016 12:27:05 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: POSIX permission mapping and NULL SIDs
Message-ID:	<20160628102705.GA22797@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<D392BA70.95D4%billziss AT navimatics DOT com> <20160624195144 DOT GB27089 AT calimero DOT vinschen DOT de> <D392F074.962E%billziss AT navimatics DOT com> <20160624215948 DOT GD27089 AT calimero DOT vinschen DOT de> <D39583E5.96E3%billziss AT navimatics DOT com> <1945820393 DOT 20160627122324 AT yandex DOT ru> <20160627102614 DOT GA8258 AT calimero DOT vinschen DOT de> <D396C16E.9770%billziss AT navimatics DOT com>
MIME-Version:	1.0
In-Reply-To:	<D396C16E.9770%billziss@navimatics.com>
User-Agent:	Mutt/1.6.1 (2016-04-27)

--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jun 27 19:01, Bill Zissimopoulos wrote:
>=20
> >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"?
>=20
> 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:
>=20
> S-1-5-X-RID                          <=3D> uid/gid: 0x1000 * X + RID
>=20
> With X=3D15 and RID=3D4095, we get uid=3D=3D65534.

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=E2=80=9D according to the =E2=80=9CWell-known =
security
> identifiers in Windows operating systems=E2=80=9D document [WKSID]. OTOH,=
 because
> S-1-5-15 is a =E2=80=9Cleaf=E2=80=9D SID and not a =E2=80=9Cnamespace=E2=
=80=9D 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:
>=20
> /*
>  * 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=3D1-15,17-21,32,64,80,83)
>  * 0x010000 + 0x100 * X + Y    S-1-X-Y ([WKSID]: X=3D1,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:
>=20
> 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

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

--RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXclD5AAoJEPU2Bp2uRE+g2KcP+wd98vGFmM2j3QQ3Vzd1fnQM
s4cEWH7pxJAsLeL3TlaKIEf/OHHKf67ZAitmGH5eZil1cpuIi2iAPxQ6q9jKKQ92
+gbQbE/KUR58mgy8Ljm/86hBZEnGQogRkecr9raZ2k/WIiNVUdNxAjrrCdq/8Xxj
8Bbkn7s11H7rq9vHM96Z9UOBgN8289Z4PleuGi9X4rTBclgvSb8dYZnEpw0P9CCG
Jyi19W8LPBxUAkQywmmuGgDjHq5lL9FdnAtUwRLqP7wqqoTfY2XZ2yoBPuFCbV4K
M6O3tWv32gqBZN0Mb7vhvimjJwdFh+Rv9q/G0bc6lNlx8WKU64spuugpnoVT+PDp
IszmbLjr3dipgCk7QcikpBk8lWgvLnOWs97ThNeoHPlfzGL13A2q9eI48SnVLCOC
tgGWFo38x4g2X+97E2costdiN5ZsRQxmK2xEWBVn2fE6mOatzw0CbGBjqAe90bQq
5qB+1/GWDS9g9IQix/x3tdD6UaEtZNGft9GfbRsA/aDVIfd7eBrB2zVfoo7ZEHOG
+V6/IAlVc49bLNUEJpxy8msWqQPrKE2Ue44sMj7j/znU4sHwO3T8mdDxx64liG0s
GjaQxlL2SXQgMTTxFP4c1BsKT2FSxPf+A+N85QKeV6Wsrf69+bV6aN/CiOuK3ibL
uJ/sr/S56oWrrLVi3sNF
=C27t
-----END PGP SIGNATURE-----

--RnlQjJ0d97Da+TV1--

- Raw text -