Katalog, który użytkownik może odczytać, ale root nie?

9

Pod moim homedirem znajduje się katalog o nazwie „.gvfs”. Jako moje zwykłe konto użytkownika mogę je dobrze przeczytać:

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

Jednak jako root nie mogę „ls” ani nawet „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

I tylko dla pewności:

# echo $UID $EUID
0 0

To tylko prosta domowa instalacja Ubuntu 8.10, bez NFS lub czegokolwiek takiego dziwnego. Widzę, że katalog jest oznaczony jako nieczytelny dla świata (i nie-zdolny do x-świata), ale pomyślałem, że żaden z nich nie jest stosowany, gdy jesteś rootem. Na przykład mogę utworzyć katalog trybu-000 w / tmp i przekazać go użytkownikowi innemu niż root, a root nie będzie miał problemu z odczytaniem go, napisaniem go, cokolwiek.

Masz pomysł, co się dzieje?

linux security unix permissions filesystems raldi
źródło
Co ciekawe, te same symptomy występują podczas używania sshfs jako zwykłego użytkownika, a następnie próby jakiejkolwiek operacji na punkcie montowania jako root. Użytkownik root nie ma żadnych uprawnień do wyświetlania punktu podłączenia. Nie możesz nawet zobaczyć uprawnień, ls -l zwraca wszystkie znaki zapytania dla wszystkich bitów uprawnień.
GodEater
1
„To tylko prosta domowa instalacja Ubuntu 8.10, bez NFS lub czegokolwiek takiego dziwnego”. Uhm, bezpiecznik to „coś dziwnego”
Thomas

Odpowiedzi:

21

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

To wszystko jest niefortunne, ale decyzja podjęta przez bezpieczników na poziomie jądra (użytkownik inny niż ten, który zamontował fs nie może uzyskać do niego dostępu, w tym root) i nic nie możemy na to poradzić.

Zobacz także: https://bugs.launchpad.net/gvfs/+bug/225361

Wydaje się, że rozwiązaniem jest aktualizacja pliku /etc/fuse.conf i włączenie opcji user_allow_other . Być może będziesz musiał uzyskać gvfs, aby przekazać parametr allow_root lub allow_other, ale nie jestem pewien, jak to zrobić.

Oczywiście może być o wiele łatwiej po prostu zrezygnować ze wszystkich narzędzi GUI, takich jak gvfs i zamontować systemy plików z wiersza poleceń, w którym masz pełną kontrolę nad tym, jak coś się zamontuje.

Zoredache
źródło
5

.gvfsKatalog jest Gnome VFS Strefa systemem plików, który zapewnia bezpośrednią ścieżkę systemu plików dla wirtualnych systemów plików (np zdalne wierzchowce Samba, WebDAV wierzchowce) tak Gnome może przechodzić ścieżki do programów, które nie są świadome VFS podczas pracy na zdalnych plikach.

Ponieważ jest to instalacja i aplikacja FUSE, może odmówić uprawnień do rootowania - w tym przypadku agentem wykonującym kontrolę dostępu jest aplikacja FUSE, a nie jądro.

Domyślnie gvfsdemon pozwala właścicielowi tylko na przeglądanie katalogu.

MikeyB
źródło
0

Może to być kilka rzeczy, w kolejności prawdopodobieństwa

  • sprawdź / var / log / messages (lub / var / log / syslog) pod kątem możliwego uszkodzenia systemu plików
  • używasz SELinux?
  • Google sugeruje, że lsattr ~ raldi / .gvfs może wskazywać na zastosowanie specjalnych możliwości do tego pliku.
Dave Cheney
źródło
Uruchomiłem fsck na dysku i nie znalazłem żadnych problemów. Nie używam SELinux. Jeśli uruchomię lsattr jako moje konto użytkownika, nie ma danych wyjściowych. Jeśli uruchomię go jako root, pojawia się błąd „odmowa uprawnień”.
raldi
Wygląda na to, że Zoredache ma odpowiedź
Dave Cheney