CODEWITHSUNDEEP
git
Scott Bishop
Scott Bishop

Reputation: 246

Unsafe repository owned by someone else, ok, but WHO?

I'm trying to git pull and I'm blocked by this error:

fatal: unsafe repository ... is owned by someone else)

I've read CVE-2022-24765 but nothing says how to find out who "someone else" is.

This is a really frustrating error message. It's an alarm that doesn't tell you any crucial information and instead just tells you how to disable the alarm.

Upvotes: 5

Views: 3144

Answers (2)

Scott Bishop
Scott Bishop

Reputation: 246

OP here, based on @ElpieKay suggestion I tried ls -l in a few directories and discovered that I had committed some files while logged into my Github work account.

Upvotes: 0

VonC
VonC

Reputation: 1328152

This is because of CVE-2022-24765

a malicious actor could create a .git directory in a shared location above a victim’s current working directory.
On Windows, for example, an attacker could create C:\.git\config, which would cause all git invocations that occur outside a repository to read its configured values.

safe.txt adds:

By default, Git will refuse to even parse a Git config of a repository owned by someone else, let alone run its hooks, and this config setting allows users to specify exceptions, e.g. for intentionally shared repositories

So the "someone else" is: anyone having access to your computer, and in a folder which is not explicitly listed as "safe".

More details in commit 8959555:

It poses a security risk to search for a git directory outside of the directories owned by the current user.

For example, it is common e.g. in computer pools of educational institutes to have a "scratch" space: a mounted disk with plenty of space that is regularly swiped where any authenticated user can create a directory to do their work.
Merely navigating to such a space with a Git-enabled PS1 when there is a maliciously-crafted /scratch/.git/ can lead to a compromised account.

The same holds true in multi-user setups running Windows, as C:\ is writable to every authenticated user by default.

To plug this vulnerability, we stop Git from accepting top-level directories owned by someone other than the current user. We avoid looking at the ownership of each and every directory between the current and the top-level one (if there are any between) to avoid introducing a performance bottleneck.

This new default behavior is obviously incompatible with the concept of shared repositories, where we expect the top-level directory to be owned by only one of its legitimate users. To re-enable that use case, we add support for adding exceptions from the new default behavior via the config setting safe.directory.

Upvotes: 4

Related Questions