The "TrustedInstaller" user can not be found by ID

[Corinna Vinschen]

On Jul  6 13:32, Andrey Repin wrote:
> Greetings, All!
> 
> Been doing some housekeeping in my Cygwin installation at work, and wanted to
> change the owner of the files to something other than myself.
> TrustedInstaller seemed like a good neutral target, but it took me a little
> while to find out it is
> 
> 1. …named "NT SERVICE+TrustedInstaller" actually (which is predictable
> somewhat);
> $ getent passwd | grep -i trust
> NT SERVICE+TrustedInstaller:*:328384:328384:U-NT SERVICE\TrustedInstaller,S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464:/:/sbin/nologin
>
> 2. …can not be accessed by any other name (unlike "NT AUTHORITY\SYSTEM");
> $ getent passwd System
> system:*:18:18:U-NT AUTHORITY\system,S-1-5-18:/home/system:/bin/bash
> $ getent passwd 18
> система:*:18:18:U-NT AUTHORITY\система,S-1-5-18:/home/система:/bin/bash

This is by design.  Only builtin stuff and the primary domain members
can be accessed name-only.  "NT SERVICE" is not builtin, but rather a
kind of foreign domain identifier (but don't take this literally), so
you have to use the full name "NT SERVICE+TrustedInstaller".  Note
that this is a restriction in the Windows function LookupAccountName,
as documented in the source:

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/uinfo.cc;hb=HEAD#l2032

> 3. …can not be accessed by ID! Which is rather surprising.
> $ getent passwd 328384
> [2] <- user not found
> 
> Is this some special case of some kind of Windows' kinks?

This is impossible with the current code.  Cygwin tries to perform
bijective SID<->id mappings, if possible.  "NT SERVICE" accounts are a
bit of a problem and TrustedInstaller is no exception in that the SIDs
don't follow the usual rules for BUILTIN / NT AUTHORITY / normal
accounts.  They are also not exactly predictable, even though
TrustedInstaller always has the same SID on all systems. To handle
328384 as TrustedInstaller, it needs actual special casing.  We can add
that, but that would only allow the explicit mapping between "NT
SERVICE+TrustedInstaller" and uid/gid 328384.  This would not cover
other NT SERVICE accounts.

Given that TrustedInstaller is only used by the OS at installation time,
I always looked at it as a kind of "read-only account".  I'm really not
sure if it's worth special casing this account just to allow id->SID
mapping...


Corinna