Windows well-known-sids

[amalachow]

During a recent upgrade we noted a change in behavior when running Git in a Window's container. We were able to narrow down to a the change starting with 2.46.0.windows.1 persisting through the latest releases (related #5137).

Digging into the msys-runtime diffs between the last working (2.45.2.windows.1), the change stems what I believe is a combination of a24bc22 and 8f9fcab. Specifically the SID for the ContainerAdministrator is S-1-5-93-2-1 which is matching the condition if (acc_type == SidTypeUser && (sid_sub_auth_count (sid) <= 3 || sid_id_auth (sid) == 11)). This correctly allows for NSS_SCHEME_ENV in get_home; however, the local home isn't being propagated into the in memory passwd any longer when a builtin account is forced into the SidTypeWellKnownGroup type but is not well_known_system_sid. It looks like its intentional to stop altering the home resolution for non-user's but I'm trying to understand the subauthority logic that's employed.

Reading through Microsoft's SID documentation there isn't any clear indication that the number of subauthorities would be indicative of a builtin account per the comment in uinfo.cc, Builtin account? SYSTEM, for instance, is returned as SidTypeUser, if a process is running as LocalSystem service. Is this an optimization to avoid the use of IsWellKnownSid with WinBuiltinDomainSid or are is there supporting documentation that the subauthority count less than or equal to 3 is viable to disambiguate that of a domain identifier? Trying to improve my comprehension of the logic but finding Microsoft's documentation on the APIs and details hard to discover.

Naively iterating the WELL_KNOWN_SID_TYPE enum calling CreateWellKnownSid would indicate that the subauthority count for the local machine will be strictly less than 3 in all instances except WinUserModeDriversSid, which is contradictory to the logic above though I'm not sure it'd sufficiently cover the breadth of Windows versions etc.