Ich habe einen Projektordner, der für alle Dateien unübersichtliche Berechtigungen hat. Ich hatte die schlechte Angewohnheit, alles auf Oktalberechtigungen 777 zu setzen, weil das alle nicht sicherheitsrelevanten Probleme löste. Dann haben FTP-Uploads, von Texteditoren erstellte Dateien usw. ihre eigenen Berechtigungen, was alles durcheinander bringt. Ich habe beschlossen, mich zusammenzureißen und die Berechtigungen so zu verwenden, wie sie verwendet werden sollen.
Ich dachte, 664 wäre ein guter Standard für alle meine Dateien und Ordner, und ich würde einfach die Berechtigungen anderer für private Dateien entfernen und +x für ausführbare Dateien hinzufügen.
Als ich meinen Projektordner jedoch auf 664 geändert habe:
$ sudo chmod -R 664 . $ ls ls: Verzeichnis kann nicht geöffnet werden.: Berechtigung verweigert
Das ergibt für mich keinen Sinn. Ich habe Lese-/Schreibberechtigung und bin der Eigentümer des Projektordners. Der ganz linke Teil ls -lin meinem Projektordner sieht so aus:
-rw-rw-r-- 1 Codemonkey, Codemonkey … drw-rw-r-- 5 Codemonkey Codemonkey … -rw-rw-r-- 1 Codemonkey, Codemonkey … -rw-rw-r-- 1 Codemonkey, Codemonkey … drw-rw-r-- 3 Codemonkey Codemonkey … -rw-rw-r-- 1 Codemonkey, Codemonkey … -rw-rw-r-- 1 Codemonkey, Codemonkey … -rw-rw-r-- 1 Codemonkey, Codemonkey … drw-rw-r-- 4 Codemonkey Codemonkey … drw-rw-r-- 5 Codemonkey Codemonkey …
Ich nehme an, das hat etwas mit den Berechtigungen für die Verzeichnisse zu tun, aberWas?
Antwort1
Das Ausführungsbit wird benötigt, um ein *nix-Verzeichnis zu durchlaufen. Sie können nicht cdin ein Verzeichnis wechseln, für das Sie keine Ausführungsberechtigung haben, und dies wirkt sich auf nicht offensichtliche Weise auf eine Reihe von Dienstprogrammen aus, wenn diese einen Verzeichniskontext benötigen. Bedenken Sie:
$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo
# You can read the contents of the directory, but ls still complains.
$ ls foo
ls: cannot access foo/bar: Permission denied
bar
# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied
Der Grund dafür ist die Funktionsweise von stat(). Auszug aus man 2 stat:
Für die Datei selbst sind keine Berechtigungen erforderlich. Im Fall von stat() und lstat() ist jedoch die Ausführungsberechtigung (Suche) für alle Verzeichnisse im Pfad erforderlich, die zur Datei führen.
Unterm Strich chmodwird eine rekursive Operation selten das Erwartete bewirken und die Lese- und Ausführungsberechtigungen für Verzeichnisse durcheinanderbringen, was zu unerwarteten Ergebnissen wie Ihrem führen kann. Behandeln Sie Verzeichnisberechtigungen immer getrennt von Dateiberechtigungen, um optimale Ergebnisse zu erzielen.
Antwort2
Sie benötigen Ausführungsberechtigungen für Verzeichnisse.
In Betracht ziehen
sudo find -type d -exec chmod +x {} +
Update: Hier ist meine Erklärung für diese anscheinend seltsame Verwendung von Ausführungsberechtigungen.
Unix (und damit auch Linux) behandelt praktisch alles als Datei. Dies gilt auch für Festplatten und verschiedene andere Geräte. Es umfasst auch Verzeichnisse.
Herkömmliche Unix-Dateisysteme verfügen über eine Reihe von Berechtigungen, die für Dateien gelten. Daher mussten sich die Unix-Entwickler für jedes Berechtigungsbit etwas Nützliches einfallen lassen, was es tun kann, wenn es auf eine „Datei“ angewendet wird, die keine normale Datendatei ist.
Betrachten wir Verzeichnisse. Zunächst erscheint es sinnvoll, nur die Leseberechtigung zu verwenden, um zu entscheiden, ob jemand auf das Verzeichnis zugreifen kann - beispielsweise um eine Auflistung der darin enthaltenen Dateien und ihrer Größen und Datumsstempel usw. zu erstellen.
Angenommen, Sie möchten, dass normale Benutzer Programme in /usr/local/bin ausführen können, aber nicht, dass sie in /usr/local herumstöbern können, um zu sehen, was dort ist. Wenn Sie nur die Leseberechtigung haben, können Sie dies nicht verhindern.
Die ansonsten redundante Ausführungsberechtigung wurde verwendet, um zu steuern, ob Ihre Shell ein Verzeichnis „durchqueren“ darf. Damit ist gemeint, dass Sie nicht mehr herausfinden müssen, als nötig ist, um die Details eines Unterverzeichnisses als Teil eines Pfads finden und lesen zu können. Dadurch können Sie nur so weit in das Verzeichnis /usr/local gelangen, wie es zum Lesen des Inhalts von /usr/local/bin erforderlich ist.
Also bedeutet +x auf /usr/local, dass Sie "/usr/local/bin/foo" ausführen können. Aber +r auf /usr/local bedeutet, dass Sie alles herausfinden können, was sich in /usr/local befindet, einschließlich wem es gehört, welche Berechtigungen jede Datei hat, wie groß sie war usw.
Das Obige basiert auf vagen Erinnerungen und Vermutungen. Es ist vielleicht nicht ganz richtig, aber ich glaube, es vermittelt eine vernünftige Vorstellung davon, warum „ausführen“ „durchqueren können“ bedeutet.