Verzeichnis, das ein Benutzer lesen kann, root jedoch nicht?

9

Unter meinem Homedir befindet sich ein Verzeichnis namens ".gvfs". Als mein reguläres Benutzerkonto kann ich es gut lesen:

~ $ ls -lart ~raldi/.gvfs
total 4
dr-x------  2 raldi raldi    0 2009-05-25 22:17 .
drwxr-xr-x 60 raldi raldi 4096 2009-05-25 23:08 ..
~ $ ls -d ~raldi/.gvfs
dr-x------ 2 raldi raldi 0 2009-05-25 22:17 /home/raldi/.gvfs

Als root kann ich es jedoch nicht "ls" oder sogar "ls -d":

# ls ~raldi/.gvfs
ls: cannot access /home/raldi/.gvfs: Permission denied
# ls -d ~raldi/.gvfs
ls: cannot access /home/raldi/.gvfs: Permission denied

Und nur um sicherzugehen:

# echo $UID $EUID
0 0

Dies ist nur eine einfache Heiminstallation von Ubuntu 8.10, kein NFS oder ähnliches. Ich sehe, dass das Verzeichnis als nicht weltlesbar (und nicht welt-x-fähig) markiert ist, aber ich dachte, dass nichts davon angewendet wird, wenn Sie root sind. Zum Beispiel kann ich ein mode-000-Verzeichnis in / tmp erstellen und es an einen Nicht-Root-Benutzer weitergeben, und root hat keine Probleme, es zu lesen, zu schreiben, was auch immer.

Irgendeine Idee, was los ist?

— Raldi
quelle

Interessanterweise treten dieselben Symptome auf, wenn Sie sshfs als regulären Benutzer verwenden und dann versuchen, eine Operation auf dem Mount-Punkt als Root auszuführen. Der Root-Benutzer hat überhaupt keine Berechtigung zum Anzeigen des Mount-Punkts. Sie können nicht einmal die Berechtigungen sehen, ls -l gibt alle Fragezeichen für alle Berechtigungsbits zurück.

— GodEater

1

"Dies ist nur eine einfache Heiminstallation von Ubuntu 8.10, kein NFS oder ähnliches." Ähm, Sicherung ist "so etwas Seltsames"

— Thomas

21

Von: http://bugzilla.gnome.org/show_bug.cgi?id=534284

Dies ist alles unglücklich, aber es ist eine Entscheidung, die von den Fuse-Leuten auf Kernel-Ebene getroffen wurde (Benutzer, die nicht die fs gemountet haben, können nicht darauf zugreifen, einschließlich root), und wir können nichts dagegen tun.

Siehe auch: https://bugs.launchpad.net/gvfs/+bug/225361

Die Lösung scheint darin zu bestehen, Ihre Datei /etc/fuse.conf zu aktualisieren und die Option user_allow_other zu aktivieren . Möglicherweise müssen Sie dann auch gvfs dazu bringen, allow_root oder allow_other zu übergeben, aber ich bin mir nicht sicher, wie ich das tun soll.

Natürlich kann es viel einfacher sein, einfach alle GUI-Tools wie gvfs aufzugeben und Ihre Dateisysteme über die Befehlszeile zu mounten, wo Sie die vollständige Kontrolle darüber haben, wie etwas gemountet wird.

— Zoredache
quelle

5

Das .gvfsVerzeichnis ist das Gnome VFS-Benutzerbereich-Dateisystem, das einen direkten Dateisystempfad für virtuelle Dateisysteme bereitstellt (z. B. Remote-Samba-Mounts, Webdav-Mounts), sodass Gnome Pfade an Programme übergeben kann, die bei der Arbeit mit Remote-Dateien nicht VFS-fähig sind.

Da es sich um eine FUSE-Bereitstellung und -Anwendung handelt, können Root-Berechtigungen verweigert werden. In diesem Fall ist der Agent, der die Zugriffsprüfungen durchführt, die FUSE-Anwendung und nicht der Kernel.

Standardmäßig gvfserlaubt der Daemon dem Eigentümer nur, das Verzeichnis zu durchlaufen.

— MikeyB
quelle

0

Es könnten ein paar Dinge sein, in der Reihenfolge der Wahrscheinlichkeit

Überprüfen Sie / var / log / messages (oder / var / log / syslog) auf mögliche Beschädigungen des Dateisystems
Verwenden Sie SELinux?
Google schlägt vor, dass lsattr ~ raldi / .gvfs möglicherweise auf spezielle Funktionen hinweist, die auf diese Datei angewendet werden.

— Dave Cheney
quelle

Ich habe fsck auf der Festplatte ausgeführt und es wurden keine Probleme gefunden. Ich benutze kein SELinux. Wenn ich lsattr als mein Benutzerkonto ausführe, erfolgt keine Ausgabe. Wenn ich es als root ausführe, erhalte ich den Fehler "Berechtigung verweigert".

— Raldi

Sieht aus wie Zoredache die Antwort hat

— Dave Cheney