Fix clone ownership under Windows Administrator Protection

[tyrielv]

Problem

Under Windows Administrator protection (AP), an elevated process runs as a hidden, profile-separated shadow admin account (MACHINE\admin_<user>) whose SID is a local account (S-1-5-21-…) that differs from the real, non-elevated user's SID.

When gvfs clone runs elevated, the enlistment's src and .git directories are created owned by the Administrators group. EnsureDirectoryIsOwnedByCurrentUser then reassigned ownership to the current user to satisfy git's dubious-ownership check. Under AP the "current user" is the shadow admin, so ownership was set to admin_<user>.

The real (non-elevated) user then hits:

fatal: detected dubious ownership in repository

because git's Administrators-group-membership grace does not cover another specific user's SID, and the shadow admin cannot SetOwner to the real user's SID either.

Fix

Detect the AP shadow admin from the running process's own token (its effective elevation identity) and, when present, leave the directory owner as the Administrators group instead of reassigning it to the shadow admin.

An Administrators-owned directory is accepted by modern git and the libgit2 non-elevated-admin-owner overlay for any Administrators member — the real user, the shadow admin, and SYSTEM (for automount) alike. So skipping the reassignment for a shadow admin is correct for every consumer. When the current user is not a shadow admin, behavior is unchanged (owner reassigned to the current user, as before).

Why token-based, not TypeOfAdminApprovalMode

An earlier revision read the TypeOfAdminApprovalMode policy value. That reflects the pending policy, not the effective state: across an AP enable/disable that hasn't been rebooted, the policy value and the actual elevation behavior disagree, so the guard would misfire (e.g. policy reads 1 but elevation still yields a shadow admin → bug persists). Inspecting the process token is reboot-independent and targets the actual failure condition.

A shadow admin is identified as a local account SID (S-1-5-21-…, IsAccountSid()) whose ProfileList profile directory is ADMIN_-prefixed. The real interactive user (a domain / Entra ID account, e.g. S-1-12-1-…) is excluded.

Why not also set safe.directory

Considered and deliberately rejected. safe.directory would let stock libgit2 consumers (those lacking the non-elevated-admin-owner overlay) open an Administrators-owned repo regardless of owner. But:

• git ignores safe.directory in repo-local config (security), so it only works from global/user or system config — there is no clean repo-scoped place to write it.
• --global under an elevated clone lands in the shadow admin's profile (ADMIN_<user>\.gitconfig), which does the real user no good.
• Covering the real user would require the elevated shadow-admin process to mutate the real user's global gitconfig (invasive) or write machine-wide system config (per-repo pollution affecting all users).
• The GVFS-supported toolchain already works with Administrators ownership: microsoft/git has the Administrators-membership fix, and GVFS's bundled libgit2 carries the overlay. Only non-GVFS third-party stock-libgit2 tools are unaffected by the fix, and the non-AP elevated-clone path likewise relies purely on ownership (no safe.directory).

Leaving safe.directory untouched keeps the AP and non-AP paths symmetric and avoids cross-user config mutation.

Changes

• GVFS.Platform.Windows/WindowsPlatform.cs — add IsCurrentUserAdminProtectionShadowAccount() (inspects the current token + ProfileList).
• GVFS.Platform.Windows/WindowsFileSystem.cs — in EnsureDirectoryIsOwnedByCurrentUser, skip the Administrators→current-user reassignment when the current user is an AP shadow admin.

Testing

Builds clean (GVFS.Platform.Windows, 0 warnings / 0 errors).

Detection logic validated on a real AP machine against the live SIDs:

• real user S-1-12-1-… → IsAccountSid=False → not shadow (reassignment proceeds).
• shadow admin S-1-5-21-…-1001 → profile ADMIN_<user> → shadow (reassignment skipped).

End-to-end, on a real AP machine in the effective-AP state, using an installed build of this branch:

Check	Result
Elevated gvfs clone (runs as shadow admin)	Succeeded, mounted
Owner of src	BUILTIN\Administrators (not admin_<user>)
Owner of src\.git	BUILTIN\Administrators
Non-elevated real user git status / git rev-parse	Exit 0 — no dubious ownership error

Pre-fix, those directories would have been owned by the shadow admin, and the real user would have hit fatal: detected dubious ownership.

Related

• Original elevated-clone ownership fix: Fix ownership when cloning elevated #1829 (4e23d28a).