DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-id:content-transfer-encoding
	:mime-version; q=dns; s=default; b=wmeTbpWDbZR3fE24sH8aqrIOXRlyz
	P+7nGXjWyp2MJkqzG0MQzapQtp/KOuzOmnIMsSuPARFmMb9AEMXlGrReg2Uj+eqL
	RT9dt+xkbsrW6o1hsSJTnxjAnLSOt+rBTIZX+kCJJfhGsXUnkAbLplDL1oQIotl5
	iqSzyG3zsFt+K8=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: Bill Zissimopoulos <billziss AT navimatics DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: POSIX permission mapping and NULL SIDs
Date: Sun, 26 Jun 2016 20:46:58 +0000
Message-ID: <D39583E5.96E3%billziss@navimatics.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>
In-Reply-To: <20160624215948.GD27089@calimero.vinschen.de>
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-office365-filtering-correlation-id: 1f58504a-87ef-402e-9cc2-08d39e0304b4
x-microsoft-exchange-diagnostics: 1;CY1PR07MB2198;6:naSqeO8eDHyCjYvcLP7u+k4e0U7qk+gqmQivehmHdBBtaHBZ/zUmTvFJ0Am/MlMOf9a+NcyTlhTyDAAhGqFt+kUhpVjRPjx0fdl34pxmrSSFeZrc7w2L3P84BJsce7e6sxR70ZpnPisHb+0YgGGLqdmcOly0WYNfyFciZKnQdMRovzonMTnl+GdbafwbNI/43KqOI/IouaZ4jaNTd12c9LKFT7rCTIyIv1vO5XDe2MOpNRG2R4fyxBQpwHuWNWCAURUa2GbjNBu5lCm5m0W2kM2CL3gnoBbkhqM+MKZkw2FeOWo+POGxWwtt8Gh67UumZBksacUe0Ym1rcw2mW1GKQ==;5:E4UMRAHHsWaeeXAhibyCS5gd4q5I/m0iPMdSzChNBTNHzhBeKottJIuM80l3MaZPFUKrAnyGFgZO7mhd4+CrUxxq5T2p9LOg+Jt/FUWGEWX9/wJQ/ZP5j3LQWtN7I+EBbx7KJ+ddgtjk+5jYYhbiaw==;24:fQqCRN4HyYOYH/Qm8i3h4+Wk7YilA7OiBnrHrMNVEjXFqPHMO3Kd3DB7US2JdDaf8gQe0MTd3JayRB4+pKipDVtkejoM86XB02uUJ4dLxPM=;7:tPVLRRtu8bJ9Iw0iYpdQbLjSHXLBGYk1fSva4yb4rjQDBKhXXyWSKiCYz5yYWypLvA3imNRISG/Ss5Eblbv9dna02gU+99iw8gzMWx6BqVfYbsbd/TQFbwiCjlWEeVzsZGDVVWGIi5ldlYHrNOy/YhF8rIwH92be198qrNfZwTl/+dhW4Eho9mFXT20TPIN3OWBPzCrM9jZmqTKIGn5D3rwprSjA8muGmLGgXA8KGE6Y+TEHUo32HOw0dAj3sF9ZxL8FsuwHVD9As8Dmr7oxcw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2198;
x-microsoft-antispam-prvs: <CY1PR07MB2198D4F0E36026BB9A5C9F67BC200 AT CY1PR07MB2198 DOT namprd07 DOT prod DOT outlook DOT com>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046);SRVR:CY1PR07MB2198;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2198;
x-forefront-prvs: 0985DA2459
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(99286002)(6116002)(102836003)(189998001)(106356001)(2351001)(3280700002)(105586002)(3660700001)(87936001)(36756003)(106116001)(11100500001)(15975445007)(92566002)(2501003)(122556002)(86362001)(450100001)(5002640100001)(305945005)(10400500002)(101416001)(50986999)(54356999)(77096005)(7736002)(7846002)(8936002)(66066001)(19580405001)(19580395003)(81156014)(551544002)(5640700001)(2906002)(97736004)(81166006)(8676002)(2900100001)(1730700003)(93886004)(2950100001)(107886002)(110136002)(3846002)(76176999)(68736007)(586003)(94096001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR07MB2198;H:CY1PR07MB2199.namprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
received-spf: None (protection.outlook.com: navimatics.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1E5ED052FBD62F40AEF6170D0CA1BF6C AT namprd07 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
X-OriginatorOrg: navimatics.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2016 20:46:58.3192 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 21071be9-4f9a-413b-89ac-8353a5d2410a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2198
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id u5QKlPDw030739

On 6/24/16, 2:59 PM, "Corinna Vinschen" <cygwin-owner AT cygwin DOT com on behalf
of corinna-cygwin AT cygwin DOT 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