Dlaczego nie można znaleźć odczytu / uruchomienia / użytkownika / 1000 / gvfs, mimo że działa jako root?

34

Czy ktoś może mi powiedzieć, co robię źle, co to jest lub jak to naprawić? Korzystam z Fedory 18 i pojawia się błąd

[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
źródło

Nie robisz nic złego, a moją sugestią byłoby po prostu zignorowanie błędu. Jeśli nie jest to do przyjęcia, to co powiesz na wykluczenie punktu podłączenia GVFS z findwiersza poleceń?

— tripleee

33

Nie robisz nic złego i nie ma nic do naprawienia. /run/user/$uid/gvfslub ~$user/.gvfsjest punktem podłączenia interfejsu FUSE do GVFS . GVFS to wirtualna implementacja systemu plików dla Gnome, która pozwala aplikacjom Gnome na dostęp do zasobów takich jak serwery FTP lub Samba lub do zawartości plików zip takich jak katalogi lokalne. FUSE to sposób na implementację sterowników systemu plików jako kodu użytkownika (zamiast kodu jądra). Brama GVFS-FUSE sprawia, że sterowniki systemu plików GVFS są dostępne dla wszystkich aplikacji, nie tylko tych korzystających z bibliotek Gnome.

Zarządzanie granicami zaufania w systemach plików FUSE jest trudne, ponieważ sterownik systemu plików działa jako użytkownik nieuprzywilejowany, w przeciwieństwie do kodu jądra dla tradycyjnych systemów plików. Aby uniknąć komplikacji, domyślnie systemy plików FUSE są dostępne tylko dla użytkownika uruchamiającego proces sterownika. Nawet root nie może ominąć tego ograniczenia.

Jeśli szukasz pliku tylko w lokalnych systemach plików, przejdź -xdevdo find. Jeśli chcesz przeglądać wiele lokalnych systemów plików, wylicz je wszystkie.

find  / /home -xdev -name ngirc

Jeśli plik jest obecny od wczoraj, możesz spróbować locate ngirczamiast tego ( locateprzeszukuje bazę danych nazw plików, która zazwyczaj jest aktualizowana co noc).

Jeśli chcesz przejść przez punkty montowania GVFS, musisz to zrobić jako odpowiedni użytkownik.

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- przestań być zły”
źródło

Dzięki za świetne wyjaśnienie GVFS i FUSE. Próbowałem uruchomić „znajdź” jak w twoim przykładzie i zadziałało świetnie.

— kal

W jaki sposób FUSE uniemożliwia rootowi dostęp do plików? Z pewnością root ma możliwość wyłączenia takich zabezpieczeń.

— Akinos,

1

@Nat Root może zmienić identyfikator procesu na identyfikator użytkownika docelowego, więc w sensie bezpieczeństwa omijanie ochrony jest banalne. Ale funkcja kontroli dostępu w jądrze odmawia dostępu do roota. Zjawisko to występuje również w przypadku innych systemów plików, np. Root nie może uzyskać dostępu do prywatnych katalogów w systemie plików NFS bez przełączenia na identyfikator UID właściciela.

— Gilles „SO- przestań być zły”

2

aby „uniknąć komplikacji” ... Cóż, z pewnością stworzyło to jedną wielką komplikację, ponieważ nie mogę użyć polecenia mount do zamapowania ścieżki udostępniania na czystszą nazwę folderu. Odmowa dostępu do rootowania podczas korzystania z sudo mount.

— Nuzzolilo

@Nuzzolilo Nie mam pojęcia o czym mówisz. Jeśli masz problem, zadaj nowe pytanie i wyjaśnij swój scenariusz.

— Gilles „SO- przestań być zły”

10

To problem z bezpiecznikiem . Żaden użytkownik oprócz właściciela nie może czytać. Aby obejść domyślną konfigurację, spróbuj włączyć opcję user_allow_other. Ta opcja jest określona przez dodanie jej do /etc/fuse.conf. Nie ma żadnej wartości, po prostu określ opcję w pustym wierszu.

— Krzysztof
źródło

Dzięki. Naprawdę nie rozumiem, co to jest bezpiecznik, ale po przeczytaniu trochę z raportu o błędzie w twoim komentarzu i komentarzu don_crissti, domyślam się, że ma to związek z dyskiem twardym USB, który podłączyłem lub moim serwerem samby? Czy są jakieś problemy z bezpieczeństwem, które powinienem rozważyć przy włączaniu „user_allow_other” i czy są jakieś inne opcje montażu, które powinienem rozważyć? Dzięki.

— kal

1

Dzięki, ale tak naprawdę nie jest to dla mnie rozwiązanie, jeśli nikt inny nie może korzystać z systemu. Jak mogę powiedzieć, kto jest właścicielem? Próbowałem odmontować / odłączyć mój zewnętrzny dysk twardy i zamknąć serwer samby. Jedyne, co naprawdę chcę, to przeszukać cały system plików w poszukiwaniu pliku bez narażania bezpieczeństwa. Czy istnieje alternatywa dla BEZPIECZNIKA i czy istnieje sposób, aby dokładnie powiedzieć, do czego jest używany? Dzięki.

— kal

askubuntu.com/questions/715637/… Próbowałem sugestii @Christopher, ale opcje wiersza poleceń nie są przestrzegane. Podejrzewam, że automatyczne uruchamianie demona jest skonfigurowane w określony sposób, ale nie mogę znaleźć dokumentacji konfiguracji, aby to zrobić

— Nuzzolilo

3

Jeśli otrzymujesz pozwolenie i inne szczegóły dotyczące gvfs, jak poniżej

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

następnie po prostu odmontuj gvfs za pomocą następującego polecenia. Twój problem zostanie rozwiązany po wykonaniu tego procesu.

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

GVFS (GNOME Virtual File System) to wirtualny system plików dla pulpitu GNOME, który umożliwia użytkownikom łatwy dostęp do zdalnych danych za pośrednictwem SFTP, FTP, WebDAV, SMB i danych lokalnych poprzez integrację udev, dzięki czemu nie musisz się bać podczas odmontowywania .

— Mohd Meesam
źródło

3

jest to stary wątek, ale w raportach o błędach gnome jest to ostatnio otwarty problem, więc może być przydatny dla każdego, kto szuka godzin rozwiązania rozwiązania problemów z gvfs-fuser - które wydają się być ściśle powiązane.

Błąd Msg z połączenia:

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

Napotkałem problem z gvfs-fuser podczas próby użycia meld / diff / kdiff przez ftp. Wygląda na to, że problem dotyczy utrwalacza i gvfs. Problem wydaje się nie występować w wersji 3.15.1, ale zaczyna być zgłaszany w wersji 3.15.2. (Nowy python ver?) Rozwiązanie to obejście, a nie poprawka - pliki / katalogi zostaną skopiowane, ale błąd nadal jest wyświetlany.

Odpowiedź Christophera określa problem i zapewnia rozwiązanie.

Innym możliwym rozwiązaniem jest użycie sshfs (zobacz ten komentarz i ten wątek ). Aby uzyskać więcej informacji gvfs-commands, zobacz Jaka jest różnica między poleceniami gvfs a typowymi poleceniami, takimi jak cat, ls, cp?

Prawdopodobnie powiązane błędy to GNOME # 317875 i GNOME # 768281 .

— wątpić
źródło