Pourquoi ne trouve-t-on pas read / run / user / 1000 / gvfs même s’il s’exécute en tant que root?

34

Est-ce que quelqu'un peut me dire ce que je fais de mal, ce que c'est, ou comment le réparer? J'utilise Fedora 18 et j'obtiens l'erreur affichée

[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
source

Vous ne faites rien de mal et ma suggestion serait de simplement ignorer l'erreur. Si cela n’est pas acceptable, pourquoi ne pas exclure le point de montage GVFS sur la findligne de commande?

— tripleee

33

Vous ne faites rien de mal, et il n'y a rien à réparer. /run/user/$uid/gvfsou ~$user/.gvfsest le point de montage de l' interface FUSE vers GVFS . GVFS est une implémentation de système de fichiers virtuel pour Gnome, qui permet aux applications Gnome d'accéder à des ressources telles que des serveurs FTP ou Samba ou au contenu de fichiers zip comme des répertoires locaux. FUSE est un moyen d'implémenter les pilotes de système de fichiers en tant que code utilisateur (au lieu du code du noyau). La passerelle GVFS-FUSE rend les pilotes de système de fichiers GVFS accessibles à toutes les applications, et pas uniquement à celles utilisant les bibliothèques Gnome.

La gestion des limites de confiance avec les systèmes de fichiers FUSE est difficile, car le pilote de système de fichiers s'exécute en tant qu'utilisateur non privilégié, par opposition au code du noyau des systèmes de fichiers traditionnels. Pour éviter les complications, par défaut, les systèmes de fichiers FUSE sont uniquement accessibles à l'utilisateur qui exécute le processus de pilote. Même root ne peut pas contourner cette restriction.

Si vous recherchez un fichier sur des systèmes de fichiers locaux uniquement, passez -xdevà find. Si vous souhaitez traverser plusieurs systèmes de fichiers locaux, énumérez-les tous.

find  / /home -xdev -name ngirc

Si le fichier est présent depuis hier, vous pouvez essayer à la locate ngircplace ( locaterecherche dans une base de données de noms de fichiers qui est généralement mise à jour tous les soirs).

Si vous souhaitez parcourir les points de montage GVFS, vous devez le faire en tant qu'utilisateur approprié.

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, arrête de faire le mal
source

Merci pour cette excellente explication sur GVFS et FUSE. J'ai essayé de "trouver" comme dans votre exemple et cela a très bien fonctionné.

— kal

Comment FUSE empêche-t-il l'utilisateur root d'accéder aux fichiers? Root a sûrement la possibilité de désactiver de telles protections.

— Akinos

1

@Nat Root peut changer le fsuid de son processus en uid cible. Par conséquent, pour des raisons de sécurité, contourner la protection est trivial. Mais la fonction de contrôle d’accès dans le noyau refuse l’accès à la racine. Ce phénomène se produit également avec d'autres systèmes de fichiers, par exemple, root ne peut pas accéder aux répertoires privés sur NFS sans passer à l'UID du propriétaire.

— Gilles 'SO- arrête d'être méchant'

2

"éviter les complications" ... Cela a certainement créé une énorme complication, car je ne peux pas utiliser la commande mount pour mapper le chemin du partage sur un nom de dossier plus propre. Accès refusé à la racine lors de l'utilisation de sudo mount.

— Nuzzolilo

@Nuzzolilo Je n'ai aucune idée de ce dont vous parlez. Si vous avez un problème, posez une nouvelle question et veillez à expliquer votre scénario.

— Gilles, arrête de faire le mal

10

C'est un problème de fusible . Aucun utilisateur sauf le propriétaire ne peut lire. Pour contourner la configuration par défaut, essayez d'activer l'option user_allow_other. Cette option est spécifiée en l'ajoutant à /etc/fuse.conf. Il n'a pas de valeur, spécifiez simplement l'option sur une ligne vide.

— Christopher
source

Merci. Je ne comprends pas vraiment ce qu'est un fusible, mais après avoir lu un extrait du rapport de bogue dans votre commentaire et celui de don_crissti, j'imagine que cela a à voir avec un disque dur USB que j'ai branché ou mon serveur samba? Existe-t-il des problèmes de sécurité que je devrais prendre en compte lors de l'activation de "user_allow_other" et existe-t-il d'autres options de montage que je devrais envisager? Merci.

— Kal

1

Merci, mais ce n'est pas vraiment une solution pour moi si personne d'autre ne peut utiliser le système. Comment puis-je savoir qui est le propriétaire? J'ai essayé de démonter / déconnecter mon disque dur externe et d'arrêter mon serveur samba. Tout ce que je veux vraiment faire, c'est pouvoir rechercher un fichier dans tout le système de fichiers sans compromettre la sécurité. Existe-t-il une alternative à FUSE et existe-t-il un moyen de savoir exactement à quoi il sert? Merci.

— kal

askubuntu.com/questions/715637/… J'ai essayé la suggestion de @Christopher mais les options de ligne de commande ne sont pas respectées. Je suspecter que le lanceur automatique de démon est configuré d' une certaine façon , mais je ne peux pas trouver la documentation de configuration pour le faire

— Nuzzolilo

3

Si vous obtenez l'autorisation et d'autres détails pour gvfs comme suit

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

puis démontez simplement vos fichiers gvfs à l’aide de la commande suivante. Votre problème sera résolu après avoir suivi ce processus.

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

GVFS (système de fichiers virtuel GNOME) est le système de fichiers virtuel du bureau GNOME. Il permet aux utilisateurs d’accéder facilement aux données distantes via SFTP, FTP, WebDAV, SMB et les données locales via l’intégration udev. .

— Mohd Meesam
source

3

c’est un vieux fil de discussion, mais dans les rapports de bugs gnome, c’est un problème récent et ouvert, il peut donc être utile à quiconque cherche pendant des heures une solution pour résoudre les problèmes de gvfs-fuser - qui semblent tous étroitement liés.

Message d'erreur de meld:

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'.

J'ai rencontré le problème de gvfs-fuser en essayant d'utiliser meld / diff / kdiff sur ftp. Il semble que le problème se situe entre fuser et gvfs. Le problème ne semble pas se produire dans la version 3.15.1 mais commence à être signalé dans la version 3.15.2 (la nouvelle version de python?) Est une solution de contournement et non un correctif - les fichiers / répertoires seront copiés, mais l'erreur est toujours affichée.

La réponse de Christopher définit le problème et fournit la solution.

Une autre solution possible consiste à utiliser sshfs (voir ce commentaire et ce fil ). Pour plus d'informations gvfs-commands, voir Quelle est la différence entre les commandes gvfs et les commandes courantes telles que cat, ls, cp?

Les bogues potentiellement liés incluent GNOME # 317875 et GNOME # 768281 .

— doute
source