Répertoire qu'un utilisateur peut lire, mais pas root?

9

Il y a un répertoire sous mon homedir appelé ".gvfs". En tant que compte utilisateur normal, je peux le lire très bien:

~ $ 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

Cependant, en tant que root, je ne peux pas "ls" ni même "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

Et juste pour être sûr:

# echo $UID $EUID
0 0

C'est juste une simple installation à domicile d'Ubuntu 8.10, pas de NFS ou quelque chose de bizarre comme ça. Je vois que le répertoire est marqué comme non lisible par le monde (et non compatible avec le monde), mais je pensais que rien de tout cela ne s'appliquait lorsque vous êtes root. Par exemple, je peux créer un répertoire mode-000 dans / tmp et le donner à un utilisateur non root, et root n'a aucun mal à le lire, à l'écrire, peu importe.

Une idée de ce qui se passe?

— raldi
source

Fait intéressant, vous obtenez les mêmes symptômes lorsque vous utilisez sshfs en tant qu'utilisateur normal, puis tentez toute sorte d'opération sur le point de montage en tant que root. L'utilisateur root n'a aucune autorisation pour afficher le point de montage. Vous ne pouvez même pas voir les autorisations, ls -l renvoie tous les points d'interrogation pour tous les bits d'autorisation.

— GodEater

1

"Ce n'est qu'une simple installation à domicile d'Ubuntu 8.10, pas de NFS ou quelque chose de bizarre comme ça". Uhm, le fusible est "quelque chose de bizarre comme ça"

— Thomas

21

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

C'est malheureux, mais c'est une décision qui a été prise par les gens du fusible au niveau du noyau (les utilisateurs autres que celui qui a monté le fs ne peuvent pas y accéder, y compris root) et nous ne pouvons rien y faire.

Regarde aussi: https://bugs.launchpad.net/gvfs/+bug/225361

La solution semble être de mettre à jour votre /etc/fuse.conf et d'activer l' option user_allow_other . Vous devrez peut-être également demander à gvfs de passer allow_root ou allow_other, mais je ne sais pas comment procéder.

Bien sûr, il peut être beaucoup plus facile de simplement abandonner tous les outils de l'interface graphique comme gvfs et de monter vos systèmes de fichiers à partir de la ligne de commande où vous avez un contrôle complet sur la façon exacte dont quelque chose est monté.

— Zoredache
source

5

le .gvfs répertoire est le système de fichiers de l'espace utilisateur de Gnome VFS qui fournit un chemin d'accès direct au système de fichiers pour les systèmes de fichiers virtuels (par exemple, les montages samba distants, les montages webdav) afin que Gnome puisse passer des chemins vers des programmes qui ne sont pas compatibles avec VFS lorsqu'ils fonctionnent sur des fichiers distants.

Puisqu'il s'agit d'un montage et d'une application FUSE, il peut refuser les autorisations de root - l'agent effectuant les vérifications d'accès dans ce cas est l'application FUSE, pas le noyau.

Par défaut, le gvfsdémon autorise uniquement le propriétaire à parcourir le répertoire.

— MikeyB
source

0

Cela pourrait être un certain nombre de choses, par ordre de probabilité

vérifier / var / log / messages (ou / var / log / syslog) pour une éventuelle corruption du système de fichiers
utilisez-vous SELinux?
Google suggère que lsattr ~ raldi / .gvfs peut indiquer des capacités spéciales appliquées à ce fichier.

— Dave Cheney
source

J'ai exécuté fsck sur le disque et il n'a trouvé aucun problème. Je n'utilise pas SELinux. Si j'exécute lsattr comme mon compte utilisateur, il n'y a pas de sortie. Si je l'exécute en tant que root, j'obtiens une erreur "permission refusée".

— raldi

On dirait que Zoredache a la réponse

— Dave Cheney