 | Thomas Mueller on Question got closed in May 202… |
 | Thaddy de Koning on Formulier voor bewindvoerders… |
| Thaddy de Koning on Formulier voor bewindvoerders… |
| Thaddy de Koning on Formulier voor bewindvoerders… |
 | jpluimers on Belastingaangifte 2023 met Exc… |
Posted by jpluimers on 2025/03/31
A few years back I had an error happen a while on one of my Windows machines after a git pull: fatal: detected dubious ownership in repository at 'C:/versioned/repository' followed by a few lines with Windows SIDs (Security Identifiers) that I had to map to actual users.
I thought I had it scheduled, but my notes were in a draft post, so when I bumped into it again when upgrading an old virtual machine with new versions I finished it and scheduled it for now.
The first time I got the error was after git for Windows fixed security vulnerability [Wayback/Archive] CVE-2022-24765 and included the quote from [Wayback/Archive] Uncontrolled search for the Git directory in Git for Windows · Advisory · git-for-windows/git:
Impact
This vulnerability affects users working on multi-user machines, where untrusted parties have write access to the same hard disk. Those untrusted parties could create the folder
C:\.git, which would be picked up by Git operations run supposedly outside a repository while searching for a Git directory. Git would then respect any config in said Git directory.Git Bash users who set
GIT_PS1_SHOWDIRTYSTATE(as recommended in the [Wayback/Archive] Pro Git Book) are vulnerable.Users who installed [Wayback/Archive] posh-git are vulnerable simply by starting a PowerShell.
Users of IDEs such as Visual Studio are vulnerable: simply creating a new project would already read and respect the config specified in
C:\.git\config.Users of the Microsoft fork of Git are vulnerable simply by starting a Git Bash.
Patches
The problem has been patched in Git for Windows v2.35.2.
That is all cool and dandy, but the way it displays a problem is less intuitive for most Windows users, as seen in this output from my system:
C:versionedrepository> git pull fatal: detected dubious ownership in repository at 'C:/versioned/repository' 'C:/versioned/bin/.git' is owned by: 'S-1-5-21-30292461-3096126706-339483272-1001' but the current user is: 'S-1-5-21-30292461-3096126706-339483272-1004' To add an exception for this directory, call: git config --global --add safe.directory C:/versioned/repository git status fatal: detected dubious ownership in repository at 'C:/versioned/repository' 'C:/versioned/repository/.git' is owned by: 'S-1-5-21-30292461-3096126706-339483272-1001' but the current user is: 'S-1-5-21-30292461-3096126706-339483272-1004' To add an exception for this directory, call: git config --global --add safe.directory C:/versioned/repository
What you see is only the SID for each user.
I have a PowerShell script for that showing all columns for all users to help me track it down, but that is a truckload of of information:
PowerShell "Get-LocalUser | Format-Table -Property * | Out-String -Width 40960"
(it also uses the -Property* and | Out-String -Width 40960 tricks so each entry is on a line by itself).
This only gives you the SID and Name:
C:\temp>PowerShell "Get-LocalUser | Select-Object -Property SID, Name" SID Name --- ---- S-1-5-21-1522018678-69878723-2804176864-500 Administrator S-1-5-21-1522018678-69878723-2804176864-503 DefaultAccount S-1-5-21-1522018678-69878723-2804176864-1001 Gebruiker S-1-5-21-1522018678-69878723-2804176864-501 Guest S-1-5-21-1522018678-69878723-2804176864-1002 jeroenp S-1-5-21-1522018678-69878723-2804176864-504 WDAGUtilityAccount
In a similar fashion you can do these for the local groups.
All columns:
PowerShell "Get-LocalGroup | Format-Table -Property * | Out-String -Width 40960"
Only SID and Name (which has __vmware because I have VMware Player installed):
c:\temp>PowerShell "Get-LocalGroup | Select-Object -Property SID, Name" SID Name --- ---- S-1-5-21-1522018678-69878723-2804176864-1007 __vmware__ S-1-5-32-579 Access Control Assistance Operators S-1-5-32-544 Administrators S-1-5-32-551 Backup Operators S-1-5-32-569 Cryptographic Operators S-1-5-32-583 Device Owners S-1-5-32-562 Distributed COM Users S-1-5-32-573 Event Log Readers S-1-5-32-546 Guests S-1-5-32-578 Hyper-V Administrators S-1-5-32-568 IIS_IUSRS S-1-5-32-556 Network Configuration Operators S-1-5-32-559 Performance Log Users S-1-5-32-558 Performance Monitor Users S-1-5-32-547 Power Users S-1-5-32-555 Remote Desktop Users S-1-5-32-580 Remote Management Users S-1-5-32-552 Replicator S-1-5-32-581 System Managed Accounts Group S-1-5-32-545 Users
So I messed up with a Dutch system that had a default user Gebruiker before installing my own jeroenp account.
The fix was relatively easy: change the owner of C:\versioned to my own user account jeroenp in stead of Gebruiker:
As elevated administrator user, run takeown /f C:\versioned\repository\.git
Related blog posts:
whoami)Related information:
CVE-2022-24765.GIT_PS1_SHOWDIRTYSTATE which was one of the situations affected by the vulnerability)git version installed)The last value in the series, which is called the relative identifier (RID), identifies a particular account or group relative to a domain.
…
When accounts and groups are stored in an account database that’s managed by a local Security Accounts Manager (SAM), it’s fairly easy for the system to generate a unique relative identifier for each account and in a group that it creates on a standalone computer. The SAM on a standalone computer can track the relative identifier values that it has used before and make sure that it never uses them again.
takeown with icacls in his itsmine.cmdbatch file to recursively take ownership of a directory then setting the access control list (ACL) to grant rights for the Administrators (with SID S-1-5-32-544) group to it:takeown /f %1 /r /d y icacls %1 /grant administrators:F /t
So here are some links to the individual commands:
icacls and cacls, see Super User question below):
Q
Each time we reinstalled Windows, it will create a new SID for user even the username is as same as before.
// example (not real SID format, just show the problem) user SID -------------------- liuyan S-old-501 // old SID before reinstall liuyan S-new-501 // new SID after reinstallThe annoying problem after reinstall is NTFS file owership and permissions on hard drive disk are still associated with old user’s SID.
…
The [Wayback/Archive]
caclscommand line tool can’t be used in such situation, because the file does belongs to new user, so it will failed with Access is denied error. and it can’t change ownership.Even if I can change the owership via [Wayback/Archive]
SubInACLtool,caclscan’t remove the old user’s permission because the old user does not exist on new installation, and can’t copy the old user’s permission to new user.…
A
--jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment