[Bug] Scoop update fails with error - (fatal: unsafe repository)

[aungheinhtoo]

Bug Report

Current Behavior

scoop update fails with error (fatal: unsafe repository)

Expected Behavior

The update goes through.

Additional context/output

fatal: unsafe repository ('~/scoop/apps/scoop/current' is owned by someone else)
To add an exception for this directory, call:

        git config --global --add safe.directory ~/scoop/apps/scoop/current

System details

Windows 11 64-bit, PowerShell 7.2.2

Scoop Configuration

{
  "lastUpdate": "2022-04-15T00:17:14.6621939+08:00",
  "SCOOP_REPO": "https://github.com/ScoopInstaller/Scoop",
  "SCOOP_BRANCH": "master",
  "alias": {}
}

[Vixb1122]

https://github.blog/2022-04-12-git-security-vulnerability-announced/

https://git-scm.com/docs/git-config/2.35.2#Documentation/git-config.txt-safedirectory

Run git config --global --add safe.directory '*'

Everything will be OK.

[hgkamath]

I just want to add, that this situation may also be encountered when using multi-boot win-OS-es, and mounting a vhdx to a path c:\vol\scoop_01 that contains scoop and scoop-global directories under c:\vol\scoop_01\scoop and c:\vol\scoop_01\scoopg . The admin account SID in the each WinOS is different.

PS C:\> get-LocalUser  admin | Format-List
on WinOS1: admin user's SID: S-1-5-21-XXX-XXX-XXX-1004
PS C:\> get-acl C:/vol/scoop_01/scoop/buckets/extras | Format-List
file perhaps created on WinOS2: file-owner-SID: S-1-5-21-ZZZ-ZZZ-ZZZ-1001

I ended up doing the following

PS C:\> git config --global  --unset safe.directory=C:/vol/scoop_01/scoop/apps/scoop/current
PS C:\> git config --global  --unset safe.directory=C:/vol/scoop_01/scoop/buckets/extras
PS C:\> git config --global  --unset safe.directory=C:/vol/scoop_01/scoop/buckets/java
PS C:\> git config --global  --unset safe.directory=C:/vol/scoop_01/scoop/buckets/main

PS C:\> git config --global --get-all safe.directory "C:.*"
C:/vol/scoop_01/scoop/apps/scoop/current
C:/vol/scoop_01/scoop/buckets/extras
C:/vol/scoop_01/scoop/buckets/java
C:/vol/scoop_01/scoop/buckets/main

PS C:\> Get-Content C:\Users\admin\.gitconfig
[safe]
        directory = C:/vol/scoop_01/scoop/apps/scoop/current
        directory = C:/vol/scoop_01/scoop/buckets/extras
        directory = C:/vol/scoop_01/scoop/buckets/java
        directory = C:/vol/scoop_01/scoop/buckets/main

Q1) could I have also done git config --global --add safe.directory "C:/vol/scoop_01/" as they are all nested, instead of configuring safe.directory for each git repository separately ?

Also, noting

• each bucket has its own .git repository
• that this git config is global to all uses of git on the system
• the same global git config will need to be configured on each windows's git
• the alternative would be to configure git config for each git repository created by scoop

Q2) Instead of configuring global git config, could there be a feature/way to specify the git-safe.directories in the scoop config, and every time scoop makes git repositories for all the things it maintains, it could make the local git configs with specified scoop default git configurations, that way it wouldn't necessitate entries into a admin-user's global git configs ?

[rashil2000]

There has been some previous discussion regarding Scoop's own git config - https://github.com/ScoopInstaller/Scoop/issues/3707 and https://github.com/ScoopInstaller/Scoop/issues/4166

[bin456789]

I meet this problom in updating buckets. It seems you install scoop or add buckets using admin permissions. A better way to fix it is change that fatal folder's owner to your windows account.

[aungheinhtoo]

I meet this problom in updating buckets. It seems you install scoop or add buckets using admin permissions. A better way to fix it is change that fatal folder's owner to your windows account.

I think you're right. I must have done that unintentionally in an elevated shell.

[abatishchev]

Ping on this. Why it needs elevated permissions if the folder is owned by the same user? Adding safe.directory fixes the error.

[hgkamath]

Ping on this. Why it needs elevated permissions https://github.com/ScoopInstaller/Scoop/issues/4879#issuecomment-1165754037

In the case I described, on dual boot WinOS-machine, in each WinOS, machine-owner may create same spelling-username on both WinOS, but the SID could be different. Trying to take ownership for one WinOS, screws it up for the other. The suggestion to add global safe directory works. The comment raised the question Q2, if configuring a logged-in-user's global-git-settings is the way to go or instead try to make scoop configure it as a per-repository setting. See https://github.com/ScoopInstaller/Scoop/issues/4879#issuecomment-1104778354

I would like a answer to Q1, which seasoned git user may know. basically: On adding to safe directory list, can I get away with just a single top level containing directory (SCOOP_GLOBAL) which contains git repo-s somewhere down under in its folder hierarchy, or does it have to list every root-folder of each individual git repository scoop uses.

In the general case, whenever scoop uses the ``install/update -g```, it requires elevated administrative-group permissions for directories designated as SCOOP_GLOBAL as well as the ability to write to PROGDATA\..\Startup and as well as to perform other install-time admin WinOS-wide (HKEY_LOCAL_MACHINE) registry/tweaks.

One may end up in this situation if the global directories are created on one machine/virtual-machine/WinOS, and the drive is transferred/shared to another machine/virtual-machine/WinOS.

Normally, one does not share the user's SCOOP directory, but what if one did? That is another line of thought to explore.

[couleurm]

one of the users who uses some of my utilities has gotten a similar error

[29039]

I have done a comprehensive investigation on this problem.

ROOT CAUSE: Essentially what is happening, is that when you create a new file/directory in NTFS, the Ownership is not inherited no matter what, nor can I find any way to control the default owner, and who that owner is going to depend on one of two things:

• When running cmd (or other process) as non-admin, it will set the Owner to be the username.
• When running cmd (or other process) as admin, it will set the Owner to be the Administrators group.

I have not been able to figure out a way to control this behaviour (even tried removing 'change ownership' rights to no avail), and I have tested with cmd, powershell, windows terminal and doublecmd so I think that it is a problem on the NTFS level.

CAUSE as it relates to scoop: If you use scoop when running in an elevated cmd with admin level access to do anything which involves creation of a new file/directory (i.e. install with -RunAsAdmin, add a bucket, update scoop, etc.) that file/directory which is created will have either have:

• Owner: Administrators, if it was run with admin privileges
• Owner: (the current username), if it was run without admin privileges.

This is a problem because git is now sensitive to only work on files/directories owned but the same user currently running the git process.

In practice, this means that when git is run with admin privileges (as part of scoop), it is fine because it can see that the user is part of the Administrators group.

But the problem arises when running git as non-admin (as part of scoop), where previously some components were updated with admin rights, because git as a non-admin won't touch any files owned by Administrators, it needs to be owned by the current user.

It is possible to add an exception for each directory, but then you have to keep adding exceptions. Sadly, git does not accept wildcards to exclude the whole scoop folder from this behaviour.

WORKAROUNDS:

• Only ever run scoop as Admin not as non-admin, or vice versa. Don't mix the running of scoop with/without admin.

• Fix the permissions every time before running scoop: takeown /F $env:USERPROFILE\scoop /R /SKIPSL

• add each git repo to the safe.directory list - manually: git config --system --add safe.directory C:/Users/<YOUR USERNAME>/scoop/apps/scoop/current git config --system --add safe.directory C:/Users/<YOUR USERNAME>/scoop/buckets/extras git config --system --add safe.directory C:/Users/<YOUR USERNAME>/scoop/buckets/main etc.

• add each git repo to the safe.directory list - semi automatically I whipped up something in ChatGPT to do this, so I just need to run this script before running scoop each time to make sure it isn't going to encounter this problem - https://github.com/29039/ScoopyThings/blob/main/Scoop-AddGitSafeDirs.ps1

NOTES on GIT making it this way: It is possible to disable this security feature, but just looking at why gitintroduced this functionality - https://github.blog/2022-04-12-git-security-vulnerability-announced/ - This sounds very serious vulnerability and very dumb to disable this security fix.

Honestly this is a dumb 'fix' by git in the first place to use this check which is inconsistently true rather than fix the root problem of reading files from non-privileged locations (which can be maliciously be placed there by other users). But regardless, you should not disable this security feature really.

I would therefore recommend that this be re-opened as a bug and have the functionality added into scoop to take care of the problem automatically.