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=CTEmQcFn0KlmJl82/JqIhPHFNo2ZQu4P15MqfwaruMlTcm0DjBddj
	Y3dhbeQXNVcx4f+/NXozpiFxelNjIsLBpJa2Vc8E1DaIIYcuhCQV1pDTwqyMBssr
	Kw6RhgzFugNUMCcBU4b8u/Jjh3Ho3smyzwTplfiWZIsmGgxgDtY+xg=
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=T7oqGyqQ3EcUEIXRuDrOW4Gwhm4=; b=atajgMFa9xLNENPMCoy/EZcvZAN/
	ZRfQFnpqAdE5pilw53hi5A5GX9yAp55x/QyWgkVB55aZgQoXB06Wxfv8Fj09ttVt
	kw5e58uneEIsm4OCMRR+Q8JQtSVDd5cbqRdPWmQAGR67709PcyvNwFx+VghtKytN
	8aGv4tR2lE1fA/o=
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=-94.9 required=5.0 tests=AWL,BAYES_50,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=Authority, logon, 0x10063, s10
X-HELO: calimero.vinschen.de
Date: Mon, 27 Jun 2016 12:26:14 +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: <20160627102614.GA8258@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO"
Content-Disposition: inline
In-Reply-To: <1945820393.20160627122324@yandex.ru>
User-Agent: Mutt/1.6.1 (2016-04-27)

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

On Jun 27 12:23, Andrey Repin wrote:
> Greetings, Bill Zissimopoulos!
>=20
> >>> The main reason that I am weary of using an unused SID is that Micros=
oft
> >>> 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".
>=20
> > Ideally we should choose a SID that:
>=20
> > (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 wi=
th
> > Anonymous SID) above.
> > (3) Maps to a reasonable UID in Cygwin.
>=20
> > I propose the following SID/UID mapping:
>=20
> >     S-1-0-99 <=3D> UID 0xffffffff (32-bit -1)
>=20
> 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).
>=20
> > For the same reason (that it is a new/unused SID in the S-1-0) namespac=
e,
> > I think it also satisfies (2).
>=20
> > If we follow the rules from Cygwin=E2=80=99s "POSIX accounts, permissio=
n, and
> > security=E2=80=9D document [IDMAP], the SID S-1-0-99 maps to 0x10063. B=
ut 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 mappi=
ng
> > 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

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

--M9NhX3UHpAaciwkO
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCAAGBQJXcP9GAAoJEPU2Bp2uRE+g0JgP/jVjTjdpPtWhx947Grac0zYd
DnRhmvUSTcERGHHSGEMR94Mfo3+VlKsWMSxjwtwZTjmBydrR8+urO+u4WCtsvWJj
cowx19JPTJv/wAD/HLqTXBLjTbM9b+aBpKonYs5oCcNS0qidghM9yoZq4zEU9Kjh
6pOTcuB2i+6ODwz9vP3U9wHLsJi/qaJpW0TRAwfoRCwaoA15gfWwAH/tiQtHXxbb
aotnwvp1JNbk71lnpuNgxHLb3xOcfwkNKymN1RRYOJfHcdwdnfTYkB8cYaxKOE6H
jamIlsZH1qqcXDZfbriqxVTh0UkIotm2mxaz9f95z6qWPRkr74iDBBAiU1LoJyKz
jHNh/7vaf+ES+wnTtOoEx++uMarOkvCKUln6YujyI8EmvyqClRZK+j3HLPlzZqkM
ZcsYVBonBbBCmYoW0uAlxPQ+rUD32yz6+KVwjvjt+PTEfDe0VFrHbA4Q/52EUipi
MVJ8f61STJwqhTQ9NiF+5mEziJgTNQXrwZ8FqO6dc7AcD6Ut4QzvJfScLuNa0qei
eYYF4mI/KkUfj7WknHhTHcxUeyF383km1bFibJ5aRh6ESFToIfo9BkVlyiWwrf52
+bE8XS6WE++4iiUwANTbBL917lZ9e5dC2nVnMV1oT9PqbvlZ90ivngHt/ecC/61G
aLnYYhfxLuN2BaPLRFZA
=j5mm
-----END PGP SIGNATURE-----

--M9NhX3UHpAaciwkO--