The "TrustedInstaller" user can not be found by ID

[Corinna Vinschen]

On Jul  6 23:45, Andrey Repin wrote:
> Greetings, 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
> 
> That explains it, thank you.
> 
> >> 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.
> 
> I was thinking cygserver could level such troubles.
> Since name resolution coming through it more or less, it could maintain the
> mappings of uid => SID of the accounts it had seen, and respond correctly if
> `db_enum` contains "cache".

Caching is just caching, not an entirely different algorithm.  When you
use cygserver, it just asks the Cygwin DLL on behalf of another process.
The caching itself actually occurs inside the Cygwin DLL and is always
present, even without cygserver:
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-caching

Having said that, in my case, starting tcsh via mintty with no cygserver
running, I can request the info just fine:

$ getent passwd 328384
NT SERVICE+TrustedInstaller:*:328384:328384:U-NT SERVICE\TrustedInstaller,S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464:/:/sbin/nologin

If I start tcsh inside a Windows console, the above command fails, so I
guess mintty already requests the info under some circumstances so I can
happily request the cached passwd entry.

Having said that, caching doesn't help, if the info hasn't been
requested before.  You always need at least one request for "NT
SERVICE+TrustedInstaller" inside your process tree to allow a
subsequent successful reverse mapping.

Caching is nice and all, but fact is, that I can't get the info from the
OS, and that's the actual problem.

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