Directory che un utente può leggere, ma root non può?

9

Sotto il mio homedir c'è una directory chiamata ".gvfs". Come mio normale account utente, posso leggerlo bene:

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

Tuttavia, come root non posso "ls" o persino "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

E, solo per assicurarsi:

# echo $UID $EUID
0 0

Questa è solo una semplice installazione domestica di Ubuntu 8.10, niente NFS o qualcosa di strano. Vedo che la directory è contrassegnata come non leggibile dal mondo (e non in grado di x-world), ma ho pensato che nulla di tutto ciò fosse applicabile quando si è root. Ad esempio, posso creare una directory mode-000 in / tmp e consegnarla a un utente non root, e root non ha problemi a leggerlo, scriverlo, qualunque cosa.

Qualche idea di cosa stia succedendo?

— raldi
fonte

È interessante notare che si ottengono gli stessi sintomi quando si utilizza sshfs come utente normale e quindi si tenta di eseguire qualsiasi tipo di operazione sul punto di montaggio come root. L'utente root non ha autorizzazioni per visualizzare il punto di montaggio. Non puoi nemmeno vedere i permessi, ls -l restituisce tutti i punti interrogativi per tutti i bit di permesso.

— GodEater,

1

"Questa è solo una semplice installazione domestica di Ubuntu 8.10, niente NFS o qualcosa di strano". Uhm, la miccia è "qualcosa di strano"

— Thomas,

21

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

Questo è tutto sfortunato, ma è una decisione che è stata presa dalle persone fuse a livello di kernel (l'utente diverso da quello che ha montato i fs non può accedervi, incluso il root) e non c'è niente che possiamo fare al riguardo.

Vedi anche: https://bugs.launchpad.net/gvfs/+bug/225361

La soluzione sembra essere quella di aggiornare il file /etc/fuse.conf e abilitare l' opzione user_allow_other . Potrebbe anche essere necessario quindi ottenere gvfs per passare il allow_root o allow_other, ma non sono sicuro di come farlo.

Ovviamente potrebbe essere molto più semplice rinunciare a tutti gli strumenti della GUI come gvfs e montare i filesystem dalla riga di comando, dove hai il controllo completo su come viene montato qualcosa.

— Zoredache
fonte

5

La .gvfsdirectory è il filesystem dello spazio utente di Gnome VFS che fornisce un percorso diretto del filesystem per i filesystem virtuali (ad esempio montaggi di samba remoti, montaggi di webdav) in modo che Gnome possa passare percorsi a programmi che non sono sensibili a VFS quando operano su file remoti.

Poiché è un mount e un'applicazione FUSE, può negare i permessi di root: l'agente che esegue i controlli di accesso in questo caso è l'applicazione FUSE, non il kernel.

Per impostazione predefinita, il gvfsdemone consente solo al proprietario di attraversare la directory.

— MikeyB
fonte

0

Potrebbero essere alcune cose, in ordine di probabilità

controlla / var / log / messages (o / var / log / syslog) per possibili danni al filesystem
stai usando SELinux?
google suggerisce che lsattr ~ raldi / .gvfs potrebbe indicare capacità speciali applicate a quel file.

— Dave Cheney
fonte

Ho eseguito fsck sul disco e non ha riscontrato alcun problema. Non sto usando SELinux. Se eseguo lsattr come account utente, non viene generato alcun output. Se lo eseguo come root, ricevo un errore "permesso negato".

— Raldi,

Sembra che Zoredache abbia la risposta

— Dave Cheney