Por que não é possível encontrar read / run / user / 1000 / gvfs mesmo que esteja sendo executado como root?

34

Alguém pode me dizer o que estou fazendo de errado, o que é isso ou como corrigi-lo? Estou executando o Fedora 18 e recebendo o erro mostrado

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

Você não está fazendo nada de errado e minha sugestão seria simplesmente ignorar o erro. Se isso não for aceitável, que tal excluir o ponto de montagem GVFS na findlinha de comando?

— Tripleee 29/05

33

Você não está fazendo nada de errado e não há nada para consertar. /run/user/$uid/gvfsou ~$user/.gvfsé o ponto de montagem da interface do FUSE para o GVFS . GVFS é uma implementação de sistema de arquivos virtual para o Gnome, que permite que aplicativos do Gnome acessem recursos como servidores FTP ou Samba ou o conteúdo de arquivos zip, como diretórios locais. O FUSE é uma maneira de implementar os drivers do sistema de arquivos como código do usuário (em vez do código do kernel). O gateway GVFS-FUSE torna os drivers do sistema de arquivos GVFS acessíveis a todos os aplicativos, não apenas aos que usam as bibliotecas Gnome.

É difícil gerenciar limites de confiança com sistemas de arquivos FUSE, porque o driver do sistema de arquivos está sendo executado como um usuário sem privilégios, em oposição ao código do kernel para sistemas de arquivos tradicionais. Para evitar complicações, por padrão, os sistemas de arquivos FUSE são acessíveis apenas ao usuário que executa o processo do driver. Mesmo a raiz não consegue ignorar essa restrição.

Se você estiver procurando por um arquivo apenas em sistemas de arquivos locais, passe -xdevpara find. Se você deseja percorrer vários sistemas de arquivos locais, enumere todos eles.

find  / /home -xdev -name ngirc

Se o arquivo estiver presente desde ontem, você pode tentar locate ngirc( locatepesquisa em um banco de dados de nome de arquivo que geralmente é atualizado todas as noites).

Se você deseja atravessar os pontos de montagem do GVFS, precisará fazê-lo como o usuário apropriado.

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- parar de ser mau'
fonte

Obrigado pela ótima explicação sobre GVFS e FUSE. Eu tentei rodar 'find' como no seu exemplo e funcionou muito bem.

— kal 30/05

Como o FUSE impede que o root acesse os arquivos? Certamente o root tem a capacidade de desativar essas proteções.

— Akinos

1

O @Nat Root pode alterar o fsuid do seu processo para o uid de destino, portanto, no sentido da segurança, ignorar a proteção é trivial. Mas a função de controle de acesso no kernel nega acesso ao root. Esse fenômeno também acontece com outros sistemas de arquivos, por exemplo, o root não pode acessar diretórios privados no NFS sem mudar para o UID do proprietário.

— Gilles 'SO- stop be evil'

2

para "evitar complicações" ... Bem, com certeza criou uma grande complicação, pois não posso usar o comando mount para mapear o caminho de compartilhamento para um nome de pasta mais limpo. Acesso negado à raiz ao usar o sudo mount.

— Nuzzolilo 01/01

@ Nuzzolilo Eu não tenho idéia do que você está falando. Se você tiver um problema, faça uma nova pergunta e não deixe de explicar seu cenário.

— Gilles 'pare de ser mau' em

10

É uma questão de fusível . Nenhum usuário, exceto o proprietário, pode ler. Para contornar a configuração padrão, tente ativar a opção user_allow_other. Esta opção é especificada adicionando-a ao /etc/fuse.conf. Não tem valor, basta especificar a opção em uma linha em branco.

— Christopher
fonte

Obrigado. Eu realmente não entendo o que é o fusível, mas depois de ler um pouco do relatório de bug no seu comentário e no comentário de don_crissti, acho que isso tem a ver com um disco rígido USB que eu conectei ou meu servidor samba? Há algum problema de segurança que devo considerar ao ativar "user_allow_other" e existem outras opções de montagem que devo considerar? Obrigado.

— kal

1

Obrigado, mas isso não é realmente uma solução para mim, se mais ninguém puder usar o sistema. Como posso saber quem é o proprietário? Tentei desmontar / desconectar meu disco rígido externo e desligar meu servidor samba. Tudo o que realmente quero fazer é poder pesquisar um arquivo no sistema de arquivos inteiro sem comprometer a segurança. Existe uma alternativa ao FUSE e existe uma maneira de dizer exatamente para que ele está sendo usado? Obrigado.

— kal

askubuntu.com/questions/715637/… Tentei a sugestão do @Christopher, mas as opções da linha de comando não estão sendo respeitadas. Estou suspeitando que o lançador daemon auto está configurado de uma certa maneira, mas eu não posso encontrar a documentação de configuração para fazê-lo

— Nuzzolilo

3

Se você estiver obtendo a permissão e outros detalhes para gvfs, conforme a seguinte

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

desmonte seu gvfs usando o seguinte comando. Seu problema será resolvido depois de seguir esse processo.

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

O GVFS (GNOME Virtual File System) é o sistema de arquivos virtual da área de trabalho do GNOME, que permite aos usuários acesso fácil a dados remotos via SFTP, FTP, WebDAV, SMB e dados locais via integração com o udev, para que você não precise ter medo de desmontar isso. .

— Mohd Meesam
fonte

3

esse é um tópico antigo, mas nos relatórios de bugs do gnome é um problema aberto recente, portanto pode ser útil para quem procura horas por uma solução para corrigir problemas do gvfs-fuser - que parecem todos estar intimamente relacionados.

Msg de erro do 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'.

Encontrei o problema do gvfs-fuser tentando usar o meld / diff / kdiff sobre o ftp. Parece que o problema está entre o fusor e o gvfs. O problema parece não ocorrer no 3.15.1, mas começa a ser relatado no 3.15.2. (A nova versão do python?) A solução é uma solução alternativa e não uma correção - os arquivos / diretórios serão copiados, mas o erro ainda é exibido.

A resposta de Christopher define o problema e fornece a solução.

Outra solução possível é usar o sshfs (veja este comentário e este tópico ). Para obter mais informações gvfs-commands, consulte Qual é a diferença entre comandos gvfs e comandos comuns como cat, ls, cp?

Os erros possivelmente relacionados incluem o GNOME # 317875 e GNOME # 768281 .

— dúvida
fonte