Warum kann ich in nicht ausführbare Verzeichnisse wechseln, die mit sshfs gemountet sind?

538
iFreilicht

Mir ist aufgefallen, dass ich in nicht ausführbare Verzeichnisse einbinden kann, die mit angehängt sind sshfs.

Zuerst habe ich Verzeichnisse mit allen acht möglichen Modi erstellt:

$ pwd /mnt/remote $ for i in ; do mkdir test_$i; chmod $i$i$i test_$i; done $ ll total 32K d--------- 2 <user> <user> 4,0K Okt 19 12:39 test_0 d--x--x--x 2 <user> <user> 4,0K Okt 19 12:39 test_1 d-w--w--w- 2 <user> <user> 4,0K Okt 19 12:39 test_2 d-wx-wx-wx 2 <user> <user> 4,0K Okt 19 12:39 test_3 dr--r--r-- 2 <user> <user> 4,0K Okt 19 12:39 test_4 dr-xr-xr-x 2 <user> <user> 4,0K Okt 19 12:39 test_5 drw-rw-rw- 2 <user> <user> 4,0K Okt 19 12:39 test_6 drwxrwxrwx 2 <user> <user> 4,0K Okt 19 12:39 test_7

Dann habe ich einfach nachgesehen, ob ich sie cdin die beiden hineinbringen könnte.

$ for i in ; do cd test_$i; echo $?; cd /mnt/remote; done 0 0 0 0 0 0 0 0

Das cdgelingt also auch für die nicht ausführbaren Verzeichnisse, was unmöglich sein sollte. *

Entsprechend dem Vorschlag in den Kommentaren habe ich auch versucht, das Verzeichnis nach dem Öffnen aufzulisten:

$ for i in ; do cd test_$i && ls >/dev/null; echo $?; cd /mnt/remote; done ls: reading directory .: Permission denied 2 ls: reading directory .: Permission denied 2 ls: reading directory .: Permission denied 2 ls: reading directory .: Permission denied 2 0 0 0 0

Die interessanten Verzeichnisse hier sind test_4und test_6da sie Leseberechtigung haben, aber keine Ausführungsberechtigung. Allerdings lsgelingt es für sie beide. Es scheitert an test_0Durchläufen test_3, denen die Leseberechtigung fehlt.

Warum passiert das?

*: Um dies zu bestätigen, habe ich das gleiche Experiment auf meinem lokalen Rechner durchgeführt:

$ for i in ; do cd test_$i; echo $?; cd ~/work/permission_tests; done cd: permission denied: test_0 1 0 cd: permission denied: test_2 1 0 cd: permission denied: test_4 1 0 cd: permission denied: test_6 1 0

Es gibt also die erwarteten Ergebnisse dort.

0
Angenommen, Sie haben sich nicht als root bei der Remote-Site angemeldet, würde ich vermuten, dass sshfs die Berechtigungen nicht überprüft, bis sie tatsächlich etwas im Verzeichnis tun muss. Fügen Sie nach der CD ein ls hinzu und sehen Sie, ob dies gelingt - ich schätze, das wird nicht der Fall. Michael Kohne vor 6 Jahren 0
Ja, ich melde mich als normaler Benutzer an. Ich habe dieses Experiment der Frage hinzugefügt. TL: DR; `ls` kümmert sich nicht um Ausführungserlaubnis, nur um Lesen. Das Verhalten ist also dasselbe wie beim Auflisten außerhalb des Verzeichnisses. iFreilicht vor 6 Jahren 0
Technisch gesehen können Sie ls ... Da Sie nicht ausführbar sind, können Sie wirklich nicht auf die Inodes der darunter liegenden Dateien zugreifen. Ls / path / to / nonexec gibt Ihnen also die Namen der Dateien an, aber sonst nichts, da sie dazu auf die Inodes der Dateien zugreifen muss und das Verzeichnis in non-exec nicht vorhanden ist. "ls" und "ls." funktionieren nicht, da für die Verwendung von "." das Verzeichnis durchsucht werden muss. xenoid vor 6 Jahren 0
@iFreilicht Lese- und Ausführungsberechtigungen für ein Verzeichnis sind zwei verschiedene Dinge. Non-Read verhindert, dass Sie den Inhalt auflisten, während Non-Exec Sie daran hindert, dieses Verzeichnis in einem Pfad für den Zugriff auf die untergeordneten Elemente zu verwenden. Mit + x / -r können Sie die Kinder verwenden, wenn Sie deren Namen kennen. xenoid vor 6 Jahren 1
@xenoid Ah, bei weiterer Untersuchung macht 'ls' einen Soft-Fail. Es listet nichts auf, auch wenn sich Dateien im Verzeichnis befinden, aber es wird mit Code 0 beendet. Sehr interessant. iFreilicht vor 6 Jahren 0
Tatsächlich sagt die Manpage für sshfs, dass die Lesevorgänge standardmäßig asynchron sind. Daher denke ich, dass sie den Lesevorgang erst dann ausführt, wenn dies erforderlich ist, und daher auch "ls" nicht ausfällt. djsmiley2k vor 6 Jahren 0
`-o async_read führt asynchrones Lesen durch (Standard) -o sync_read führt synchrones Lesen durch.` djsmiley2k vor 6 Jahren 0
Zusätzlich zu dem, was gesagt wurde, ist "sshfs" ein FUSE-Dateisystem, und als solches "gehört" es dem Benutzer, der es gestartet hat, unabhängig von den Dateiberechtigungen. Es gibt Optionen wie "-o allow_root" und "-o allow_others", aber sie haben interessante gotchas und andere interessante Dinge passieren, wenn root "sshfs" startet. Es überrascht mich also nicht, dass Berechtigungen nicht genau das tun, was Sie von ihnen erwarten, auch wenn ich keine Details und Gründe ermitteln kann. dirkt vor 6 Jahren 2

0 Antworten auf die Frage

Verwandte Probleme