Ich kann das übergeordnete Verzeichnis nicht zu safe.directory in Git hinzufügen

Lesezeit: 6 Minuten

Schleimhose

Nach dem Aktualisieren von Git auf v2.35.2.windows.1 Ich erhalte den folgenden Fehler:

fatal: Unsicheres Repository (‘F:/GitHub/my-project’ gehört jemand anderem)
Um eine Ausnahme für dieses Verzeichnis hinzuzufügen, rufen Sie Folgendes auf:

git config –global –add safe.directory F:/GitHub/my-project

Ich habe versucht, das übergeordnete Verzeichnis meiner Projekte hinzuzufügen .gitconfigaber es geht nicht.

[safe]
    directory = F:/GitHub/
    directory = F:/Private/

Gibt es dafür eine Problemumgehung?
Was bedeutet eigentlich “‘x’ gehört jemand anderem”?

Ich möchte nicht jedes einzelne Projekt, an dem ich arbeite, dem hinzufügen .gitconfig Datei.

In meinem Fall bin ich der einzige, der an meinem Laptop arbeitet. Da ich jedoch in das Stammverzeichnis und nicht in mein Home-Verzeichnis klonen (verurteilen Sie mich nicht dafür), habe ich diesen Fehler erhalten, weil Verzeichnisse, die ich im Stammverzeichnis erstellt habe, verwendet werden sudo Gehören zur root Benutzer und nicht ich.

– Said Neamati

14. April um 1:47
Beachten Sie auch, dass die Laufwerksbuchstaben übereinstimmen müssen, sonst funktioniert dies nicht.

– lepi

14. April um 10:53 Uhr
@DrLightman: Sie können Ihre Git-Version herabstufen, und alles funktioniert gut. Sie haben die Wahl zwischen Sicherheit und einfachem Leben (aber Achtung: jetzt ist das Sicherheitsproblem bekannt, also sollten Sie regelmäßig kontrollieren, dass niemand in Ihrem System es missbraucht)

– Giacomo Catenazzi

14. April um 11:56 Uhr
Hinweis: Jetzt gibt es eine v2.35.3.windows.1 was einige Probleme behebt (die Konfigurationsmeldung ist jetzt korrigiert, und so ist es behebt das Problem (aber immer noch einzelnes Repository zu einem Zeitpunkt). (früher: es hat dir gesagt, dass du hinzufügen sollst prefixund als es sich beschwerte, fehlte ein Schrägstrich (im Falle eines Netzlaufwerks mit IP).

– Giacomo Catenazzi

19. April um 6:43 Uhr

Marcodor

Ab Git v2.35.3, sicheres Verzeichnis Überprüfungen können deaktiviert werden, was alle “unsicheren Repository”-Fehler beendet (dies funktioniert auch in die neuesten Patch-Versionen von 2.30-34).

Dies kann durch Ausführen von:

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

Es wird die folgende Einstellung zu Ihrem Global hinzufügen .gitconfig Datei:

[safe]
    directory = *

Vor dem Deaktivieren Stellen Sie sicher, dass Sie diese Sicherheitsmaßnahme verstehenund warum es existiert. Du sollte dies nicht tun wenn Ihre Repositories auf einem freigegebenen Laufwerk gespeichert sind.

Wenn Sie jedoch zu 100 % der einzige Benutzer Ihres Computers sind, und Ihre Repositories werden lokal gespeichert, dann sollte das Deaktivieren dieser Prüfung theoretisch kein erhöhtes Risiko darstellen.

Beachten Sie auch, dass Sie dies derzeit nicht mit einem Dateipfad kombinieren können, wie z Der Befehl interpretiert den Platzhalter nicht * als Betreiber pro sagen – es dauert nur die "*" Argument bedeutet “Prüfungen sicherer Repositorys deaktivieren / alle Repositorys als sicher betrachten”.

^{1 – Wenn dies in Ihrem speziellen Terminalprogramm in Windows fehlschlägt, versuchen Sie, den Platzhalter mit doppelten Anführungszeichen anstelle von einfachen (Via dieses GitHub-Problem):

git config --global --add safe.directory "*"}

Ich kann das anscheinend nicht zum Laufen bringen. Es funktioniert, wenn ich ein bestimmtes Verzeichnis angebe. Sind Sie sicher, dass diese Platzhaltereinstellung funktioniert?

– nicht rechteckig

18. April um 23:51 Uhr
Ja, habe es getestet. Git v2.35.3 auf Win10.

– Marcodor

19. April um 5:55 Uhr
Auch ich konnte das zum Laufen bringen; Ich habe es in Git Bash unter Windows ausgeführt. Dies sollte theoretisch keine Sicherheitslücken öffnen, wenn Sie das sind einziger Benutzer auf einer Maschine und ob die von Ihnen verwendeten Repositories eingeschaltet sind ein lokales Laufwerk (anstelle eines gemeinsamen). In meinem Fall bin ich der einzige Benutzer meines Windows-Rechners und meine Repositories befinden sich in einem Verzeichnis an der Basis von C: Antrieb.

– zcoop98

19. April um 20:50 Uhr
Nochmals ich, tut mir leid, aber ich dachte, ich hätte Git auf dem Server aktualisiert, auf dem ich teste, aber nein. Nachdem Sie das getan und getan haben, was zcoop98 gesagt hat, funktioniert es jetzt gut! YAY!

– Hal Burgiss

20. April um 15:50 Uhr
@zcoop98 Danke, guter Fang. Und schade! Ein Platzhalter wäre sinnvoll.

– Ascher

22. April um 15:03 Uhr

Ich wünschte, das würde für mich funktionieren … mein Ordner befindet sich in meiner WSL und es ist offensichtlich ein anderer Benutzer als mein Windows-System …

– David Thompson

17. April um 20:07 Uhr

Ich habe das gleiche Problem unter Windows nach dem Upgrade auf Version 2.35.2.windows.1 festgestellt. Ich konnte es beheben, indem ich den Ordner mit dem .git-Ordner und allen darin enthaltenen Dateien in Besitz nahm. Dies ist der Befehl, vorausgesetzt, Sie befinden sich bereits im Repo-Ordner.

takeown.exe /f . /r

Hinweis: Wenn Sie mehrere Repo-Ordner in einem Arbeitsordner haben, möchten Sie möglicherweise rekursiv den Besitz des Arbeitsordners und seiner Unterordner übernehmen. Die Ausführung dauert länger, aber Sie müssen dies nur einmal tun.

Unter cmd.exe würde der Befehl so aussehen:

takeown.exe /f C:\Users\%USERNAME%\Work /r

Oder so unter powershell.exe oder pwsh.exe:

takeown.exe /f $HOME\Work /r

Ich würde nicht empfehlen, den Besitz rekursiv zu übernehmen. Sie benötigen nur den Besitz des übergeordneten Ordners von .git und von .git selbst. Die Verwendung Ihrer Vorschläge wird beispielsweise wichtig, wenn Ihr Projekt Ordner enthält, die als Docker-Volumes verwendet werden. Die Berechtigungen in diesen Ordnern sind oft absichtlich unterschiedlich und haben keinerlei Auswirkung auf das Problem mit git.

– derpda

15. April um 0:59 Uhr
@derpda, ich stimme im Allgemeinen zu, aber Ihr Kommentar ist nur dann vollständig wahr, wenn Sie alle Git-Befehle aus dem Stammverzeichnis des Repos ausführen. Wenn Sie die Befehle aus einem Unterverzeichnis ausführen, wird der gesamte Pfad bis zum übergeordneten von .git muss dem aktuellen Benutzer gehören.

– Paläc

19. April um 17:14 Uhr
@Palec Da hast du Recht, aber in dem Beispiel, das ich für ein Docker-Volume gegeben habe, ist das Ändern des Besitzes des Verzeichnisses eine schlechte Lösung – ändere einfach das Verzeichnis mit cd stattdessen, damit Sie sicher ausführen können git.

– derpda

20. April um 0:59 Uhr

Für Ubuntu 20.xx-Benutzer Fix – 2022 UPDATE:

Das Aktualisieren von Git mit diesem PPA bietet die neueste stabile Upstream-Git-Version, die dieses Problem behebt.

sudo add-apt-repository ppa:git-core/ppa

sudo apt update

sudo apt install git

Ref: https://git-scm.com/download/linux

Ich würde nicht empfehlen, den Besitz rekursiv zu übernehmen. Sie benötigen nur den Besitz des übergeordneten Ordners von .git und von .git selbst. Die Verwendung Ihrer Vorschläge wird beispielsweise wichtig, wenn Ihr Projekt Ordner enthält, die als Docker-Volumes verwendet werden. Die Berechtigungen in diesen Ordnern sind oft absichtlich unterschiedlich und haben keinerlei Auswirkung auf das Problem mit git.

– derpda

15. April um 0:59 Uhr
@derpda, ich stimme im Allgemeinen zu, aber Ihr Kommentar ist nur dann vollständig wahr, wenn Sie alle Git-Befehle aus dem Stammverzeichnis des Repos ausführen. Wenn Sie die Befehle aus einem Unterverzeichnis ausführen, wird der gesamte Pfad bis zum übergeordneten von .git muss dem aktuellen Benutzer gehören.

– Paläc

19. April um 17:14 Uhr
@Palec Da hast du Recht, aber in dem Beispiel, das ich für ein Docker-Volume gegeben habe, ist das Ändern des Besitzes des Verzeichnisses eine schlechte Lösung – ändere einfach das Verzeichnis mit cd stattdessen, damit Sie sicher ausführen können git.

– derpda

20. April um 0:59 Uhr

Peter Mortensen

In meinem Fall an einem Ubuntu 20.04.4 System (Focal Fossa) wurde der Besitz des Projektordners auf den Anwendungsbenutzer festgelegt, z. www-Daten:www-Datenaber der Eigentümer des .git-Ordners, als er initiiert wurde, wurde auf festgelegt Wurzel: Wurzel.

Um dieses Problem zu beheben, habe ich den Besitz meines Projektordners auf geändert Wurzel: Wurzel um seinen Inhalt abzugleichen (einschließlich der .git Mappe). Dann begannen alle Git-Aktionen wie gewohnt zu funktionieren.

Bedeutet das, dass Sie alle Git-Operationen als root ausführen?

– Peter Mortensen

15. April um 15:08 Uhr
Es muss mehr passieren, da dies bei mir nicht funktioniert hat.

– Hal Burgiss

20. April um 15:30 Uhr
@PeterMortensen Nicht alle, das musste ich nur für diesen Fall und diesen Ordner alleine machen.

– Tc Blaize

22. April um 9:18 Uhr

10076600cookie-checkIch kann das übergeordnete Verzeichnis nicht zu *safe.directory* in Git hinzufügen

#cve-2022-24765 #git