Warum kann read / run / user / 1000 / gvfs nicht finden, obwohl es als root ausgeführt wird?

34

Kann mir jemand sagen, was ich falsch mache, was das ist oder wie man es repariert? Ich verwende Fedora 18 und erhalte den angezeigten Fehler

[root@servername /]# find . -name ngirc
find: `./run/user/1000/gvfs': Permission denied
[root@servername /]# 
[root@thinktank /]# pwd
/
[root@thinktank /]# ls -ltr ./run/user/1000
ls: cannot access ./run/user/1000/gvfs: Permission denied
total 0
d?????????? ? ?    ?      ?            ? gvfs
lrwxrwxrwx. 1 root root  17 May 28 12:30 X11-display -> /tmp/.X11-unix/X0
drwx------. 2 kal  kal  120 May 28 12:30 keyring-QjDw4b
drwx------. 2 kal  kal   40 May 28 12:30 gvfs-burn
drwx------. 2 kal  kal   60 May 28 12:30 krb5cc_5f0bcaf94f916d6b61696e2251a4dbb3
drwx------. 2 kal  kal   60 May 28 18:25 dconf

permissions root gvfs

— kal
quelle

Sie machen nichts falsch und mein Vorschlag wäre, den Fehler einfach zu ignorieren. Wenn dies nicht akzeptabel ist, schließen Sie den GVFS-Einhängepunkt in der findBefehlszeile aus.

— Tripleee

33

Sie machen nichts falsch und es gibt nichts zu reparieren. /run/user/$uid/gvfsoder ~$user/.gvfsist der Einhängepunkt für die FUSE- Schnittstelle zu GVFS . GVFS ist eine virtuelle Dateisystem-Implementierung für Gnome, mit der Gnome-Anwendungen auf Ressourcen wie FTP- oder Samba-Server oder auf den Inhalt von ZIP-Dateien wie lokale Verzeichnisse zugreifen können. FUSE ist eine Möglichkeit, Dateisystemtreiber als Benutzercode (anstelle von Kernelcode) zu implementieren. Das GVFS-FUSE-Gateway macht GVFS-Dateisystemtreiber für alle Anwendungen zugänglich, nicht nur für diejenigen, die Gnome-Bibliotheken verwenden.

Das Verwalten von Vertrauensgrenzen mit FUSE-Dateisystemen ist schwierig, da der Dateisystemtreiber im Gegensatz zum Kernelcode für herkömmliche Dateisysteme als nicht privilegierter Benutzer ausgeführt wird. Um Komplikationen zu vermeiden, ist der Zugriff auf FUSE-Dateisysteme standardmäßig nur dem Benutzer möglich, der den Treiberprozess ausführt. Sogar root kann diese Einschränkung nicht umgehen.

Wenn Sie nur auf lokalen Dateisystemen nach einer Datei suchen, gehen Sie -xdevzu find. Wenn Sie mehrere lokale Dateisysteme durchlaufen möchten, listen Sie alle auf.

find  / /home -xdev -name ngirc

Wenn die Datei seit gestern vorhanden ist, können Sie es locate ngircstattdessen versuchen ( locateDurchsuchen einer Dateinamensdatenbank, die normalerweise nachts aktualisiert wird).

Wenn Sie die GVFS-Einhängepunkte durchlaufen möchten, müssen Sie dies als der entsprechende Benutzer tun.

find / -name ngirc -path '/run/user/*/gvfs' -prune -o -path '/home/*/.gvfs' -prune -o -name ngirc -print
for d in /run/user/*; do su "${d##*/}" -c "find $d -name ngirc -print"; done

— Gilles 'SO - hör auf böse zu sein'
quelle

Vielen Dank für die großartige Erklärung zu GVFS und FUSE. Ich habe versucht, "find" wie in Ihrem Beispiel auszuführen, und es hat großartig funktioniert.

— kal

Wie verhindert FUSE, dass root auf die Dateien zugreift? Sicher hat root die Möglichkeit, solche Schutzfunktionen zu deaktivieren.

— Akinos

1

@Nat Root kann die fsuid seines Prozesses in die Ziel-uid ändern. Aus Sicherheitsgründen ist es daher trivial, den Schutz zu umgehen. Die Zugriffskontrollfunktion im Kernel verweigert jedoch den Zugriff auf root. Dieses Phänomen tritt auch bei anderen Dateisystemen auf, z. B. kann root nicht auf private Verzeichnisse in NFS zugreifen, ohne zur UID des Besitzers zu wechseln.

— Gilles 'SO- hör auf böse zu sein'

2

um "Komplikationen zu vermeiden" ... Nun, es hat sicher eine große Komplikation verursacht, da ich den Befehl mount nicht verwenden kann, um den Freigabepfad einem saubereren Ordnernamen zuzuordnen. Zugriff auf root verweigert, wenn sudo mount verwendet wird.

— Nuzzolilo

@Nuzzolilo Ich habe keine Ahnung, wovon du sprichst. Wenn Sie ein Problem haben, stellen Sie eine neue Frage und erläutern Sie Ihr Szenario.

— Gilles 'SO - hör auf böse zu sein'

10

Es ist ein Sicherungsproblem . Kein Benutzer außer dem Eigentümer kann lesen. Aktivieren Sie die Option user_allow_other, um die Standardkonfiguration zu umgehen. Diese Option wird durch Hinzufügen zu /etc/fuse.conf angegeben. Es hat keinen Wert, geben Sie einfach die Option in einer leeren Zeile an.

— Christopher
quelle

Vielen Dank. Ich verstehe nicht wirklich, was eine Sicherung ist, aber nachdem ich ein wenig aus dem Fehlerbericht in Ihrem Kommentar und dem Kommentar von don_crissti gelesen habe, habe ich vermutlich etwas mit einer USB-Festplatte zu tun, die ich angeschlossen habe, oder mit meinem Samba-Server? Gibt es irgendwelche Sicherheitsprobleme, die ich beim Aktivieren von "user_allow_other" berücksichtigen sollte, und gibt es andere Optionen zum Mounten, die ich berücksichtigen sollte? Vielen Dank.

— Kal

1

Danke, aber das ist keine Lösung für mich, wenn niemand das System benutzen kann. Wie kann ich feststellen, wer der Eigentümer ist? Ich habe versucht, meine externe Festplatte abzuhängen / zu trennen und meinen Samba-Server herunterzufahren. Ich möchte nur das gesamte Dateisystem nach einer Datei durchsuchen können, ohne die Sicherheit zu gefährden. Gibt es eine Alternative zu FUSE und gibt es eine Möglichkeit, genau zu sagen, wofür es verwendet wird? Vielen Dank.

— Kal

askubuntu.com/questions/715637/… Ich habe den Vorschlag von @Christopher ausprobiert, aber die Befehlszeilenoptionen werden nicht beachtet. Ich vermute, dass der automatische Launcher des Daemons auf eine bestimmte Weise konfiguriert ist, aber ich kann die Konfigurationsdokumentation dazu nicht finden

— Nuzzolilo

3

Wenn Sie die Erlaubnis und andere Details für gvfs wie folgt erhalten

d?????????? ? ?    ?      ?            ? gvfs

dann hänge einfach deine gvfs mit dem folgenden Befehl aus. Nachdem Sie diesen Vorgang ausgeführt haben, wird Ihr Problem behoben.

umount ~/gvfs(umount /run/user/112/gvfs in my case).

GVFS (GNOME Virtual File System) ist das virtuelle Dateisystem für den GNOME-Desktop, mit dem Benutzer einfach über die udev-Integration auf Remote-Daten über SFTP, FTP, WebDAV, SMB und lokale Daten zugreifen können .

— Mohd Meesam
quelle

3

Dies ist ein alter Thread, aber in GNOME-Fehlerberichten handelt es sich um ein aktuelles offenes Problem, sodass es für jeden von Nutzen sein kann, der stundenlang nach einer Lösung zur Behebung von Problemen mit gvfs-fuser sucht - die alle eng miteinander verbunden zu sein scheinen.

Fehlermeldung von Meldung:

Error copying '/media/root/5FDA03906F33F217/SAVE/rsyncTEST-usb/allusers' to '/run/user/0/gvfs/ftp:host=192.168.0.103/var/ftp/ftpd/images/PersistenceUSBs/rsync-meld/allusers'

[Errno 95] Operation not supported: '/run/user/0/gvfs/ftp:host=192.168.0.103/var/ftp/ftpd/images/PersistenceUSBs/rsync-meld/allusers'.

Beim Versuch, meld / diff / kdiff über ftp zu verwenden, ist das Problem gvfs-fuser aufgetreten. Scheint, das Problem liegt zwischen Fixiereinheit und gvfs. Das Problem scheint in 3.15.1 nicht aufzutreten, wird jedoch in 3.15.2 gemeldet. (Die neue Python-Version?) Lösung: Es handelt sich um eine Problemumgehung, die nicht behoben werden kann. Dateien / Verzeichnisse werden kopiert, der Fehler wird jedoch weiterhin angezeigt.

Christophers Antwort definiert das Problem und liefert die Lösung.

Eine andere mögliche Lösung ist die Verwendung von sshfs (siehe diesen Kommentar und diesen Thread ). Weitere Informationen gvfs-commandsfinden Sie unter Was ist der Unterschied zwischen gvfs-Befehlen und allgemeinen Befehlen wie cat, ls, cp ?.

Möglicherweise verwandte Fehler sind GNOME # 317875 und GNOME # 768281 .

— Zweifel
quelle