Warum funktioniert $ find -delete manchmal nicht?

1106
NReilingh

Ich denke, worüber ich spreche, ist dieser Teil der Manpage, der für mich kaum zu unverständlich ist:

 -löschen ... Es wird nicht versucht, einen Dateinamen mit einem `` / '' Zeichen zu löschen Pfadname relativ zu ``. '' aus Sicherheitsgründen ...

Konkret versuche ich zu tun $ find . -name '.svn' -type d -delete. Ich erkenne, dass ich -execstattdessen dafür verwenden kann, findscheint aber problemlos für andere Namen zu funktionieren, einschließlich tief in Verzeichnissen (die offensichtlich viele /Zeichen in ihren Pfadnamen enthalten).

Vielleicht ignoriert man stattdessen Dotfiles und die Dokumentation ist falsch.

4

1 Antwort auf die Frage

2
jjlin

Der "Sicherheitsgrund" besteht darin, dass findein Angreifer zwischen dem Auflisten der Dateien und dem Löschen dieser Dateien möglicherweise eine Komponente des Dateipfads so ändern muss, dass sie zu einem symbolischen Link zu einem unerwarteten Verzeichnis wird Datei mit demselben Namen aus einem unerwarteten Verzeichnis. Zum Beispiel könnten Sie am Ende löschen /etc/passwdund nicht, /tmp/foo/passwdwenn der Angreifer fooin einen Symlink verwandelt werden kann, auf den verwiesen wird /etc.

In Abschnitt 9.1.5 ("Eine sicherere Version von -exec") der GNU- Funddokumentation wird dieses Problem ausführlicher beschrieben.

Es ist der "relativ zu" Teil, der mich verwirrt hat. Ich kann nicht erkennen, warum ich eine Datei wie asdf / somefile.txt mit -delete relativ zu meinem Arbeitsverzeichnis entfernen kann, aber nicht asdf / .svn NReilingh vor 12 Jahren 0
Das `.` spricht nicht von Punktdateien wie` .svn`; es geht um die Unix-Notation für "aktuelles Verzeichnis" oder "Arbeitsverzeichnis", also `.`. In diesem Zusammenhang sehe ich keinen Sicherheitsgrund, um zwischen Punktdateien und anderen Dateien zu unterscheiden. Wollen Sie damit sagen, dass Ihr `find`-Befehl nicht mit` .svn` funktioniert, aber mit anderen Dateien? Ich kann mir nur vorstellen, dass `-delete` nicht wirklich für nicht leere Verzeichnisse funktioniert, AFAIK. jjlin vor 12 Jahren 0
In der Tat ist das verwirrend. Ich verstehe, dass `.` das Arbeitsverzeichnis ist, aber ich verstehe nicht, wie die Manpage behauptet, dass sie in ALLEN Unterverzeichnissen des relativen Arbeitsverzeichnisses fehlschlägt, wenn dies eindeutig nicht der Fall ist. NReilingh vor 12 Jahren 0
Ah. Dann kann es sehr gut der Fall sein, dass die Manpage gerade nicht mehr aktuell ist, und seitdem haben sie ein sichereres `-delete` implementiert und diese Einschränkung aufgehoben. Ich habe keinen Zugriff auf OS X-Maschinen, daher kann ich dort nicht mit Sicherheit sagen. jjlin vor 12 Jahren 0

Verwandte Probleme