* The "TrustedInstaller" user can not be found by ID @ 2022-07-06 10:32 Andrey Repin 2022-07-06 17:32 ` Corinna Vinschen 0 siblings, 1 reply; 4+ messages in thread From: Andrey Repin @ 2022-07-06 10:32 UTC (permalink / raw) To: All 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 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? -- With best regards, Andrey Repin Wednesday, July 6, 2022 13:22:14 Sorry for my terrible english... ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The "TrustedInstaller" user can not be found by ID 2022-07-06 10:32 The "TrustedInstaller" user can not be found by ID Andrey Repin @ 2022-07-06 17:32 ` Corinna Vinschen 2022-07-06 20:45 ` Andrey Repin 0 siblings, 1 reply; 4+ messages in thread From: Corinna Vinschen @ 2022-07-06 17:32 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The "TrustedInstaller" user can not be found by ID 2022-07-06 17:32 ` Corinna Vinschen @ 2022-07-06 20:45 ` Andrey Repin 2022-07-07 7:56 ` Corinna Vinschen 0 siblings, 1 reply; 4+ messages in thread From: Andrey Repin @ 2022-07-06 20:45 UTC (permalink / raw) To: Corinna Vinschen, cygwin 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". > 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... -- With best regards, Andrey Repin Wednesday, July 6, 2022 22:35:01 Sorry for my terrible english... ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The "TrustedInstaller" user can not be found by ID 2022-07-06 20:45 ` Andrey Repin @ 2022-07-07 7:56 ` Corinna Vinschen 0 siblings, 0 replies; 4+ messages in thread From: Corinna Vinschen @ 2022-07-07 7:56 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-07-07 7:56 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-06 10:32 The "TrustedInstaller" user can not be found by ID Andrey Repin 2022-07-06 17:32 ` Corinna Vinschen 2022-07-06 20:45 ` Andrey Repin 2022-07-07 7:56 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).