Existe alguma diretriz geral a seguir para saber por que recebo um erro de Permissão negada durante a execução de um comando específico?

Question

Eu recentemente tentei mover um arquivo para Sobrescreve /dev/null e encontrou um erro Permission denied . Do uso do Ubuntu nos últimos dois anos, sei que, se eu receber esse erro, preciso ser sudo para invocar o comando e, em seguida, ele será bem-sucedido. Isto é o que eu fiz para sobrescrever /dev/null .

No entanto, artbristol postou um comentário por lá dizendo que cegamente invocar sudo para executar um comando não é um bom hábito e devemos saber por que estamos sendo negados a permissão para executar esse comando antes de prosseguir. Eu tenho a tendência de concordar com ele, junto com todas as pessoas que votaram strongmente nesse comentário. Mas eu não sei como proceder para conhecer o "por que" .

Recentemente, eu deparei com essa resposta e tentei executar o comando como mencionado ( 393222 é o inode de examples.desktop arquivo em ~ ):

$ find . -inum 393222 -exec nano {} \;
find: './.gvfs': Permission denied
find: './.cache/dconf': Permission denied

A execução do comando acima abriu o arquivo examples.desktop em nano , mas também concedeu Permission denied para as duas pastas. A seguir estão os atributos das duas pastas (saída truncada de ls -la ):

drwx------  2 root   root    4096 Mar 11 21:04 .gvfs
drwx------  2 root   root    4096 Mar 11 21:04 dconf

Existe alguma diretriz geral a seguir para saber "por que" recebo um erro de Permissão negada durante a execução de um comando específico?

    

Answer 1

Você tem que usar seu cérebro um pouco e se perguntar:

O que o aplicativo realmente está tentando fazer?

Não haverá uma única resposta para isso, já que os erros de "Permissão negada" transcendem sistemas de arquivos, redes e regimes de autenticação (para citar apenas três) ... Não há uma única maneira de encontrar o problema ... do que dizer: "você provavelmente não tem permissão para fazer o que está fazendo".

Mas podemos analisar seus exemplos e descobrir onde está o problema neles.

Em mv testfile /dev/null você está lendo de ./testfile e escrevendo para /dev/ (para substituir /dev/null ). Isto é o que o mv faz quando você tenta mover um arquivo para um arquivo.

Um rápido stat testfile /dev/null /dev/ mostrará:

  File: ‘testfile’
  Size: 7944        Blocks: 16         IO Block: 4096   regular file
Device: fc01h/64513d    Inode: 5284807     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     oli)   Gid: ( 1000/     oli)
Access: 2014-03-19 11:35:42.027427288 +0000
Modify: 2014-03-19 12:25:17.343476867 +0000
Change: 2014-03-19 12:25:17.343476867 +0000
 Birth: -

  File: ‘/dev/null’
  Size: 0           Blocks: 0          IO Block: 4096   character special file
Device: 5h/5d   Inode: 31128501    Links: 1     Device type: 1,3
Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2014-03-18 14:33:16.742165089 +0000
Modify: 2014-03-18 14:33:16.742165089 +0000
Change: 2014-03-18 14:33:16.742165089 +0000
 Birth: -

  File: ‘/dev/’
  Size: 4740        Blocks: 0          IO Block: 4096   directory
Device: 5h/5d   Inode: 1025        Links: 17
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2014-03-20 09:51:04.408762425 +0000
Modify: 2014-03-20 09:51:04.396762425 +0000
Change: 2014-03-20 09:51:04.396762425 +0000
 Birth: -

• Você tem acesso de leitura a ./testfile
• Você tem acesso de gravação no dispositivo de caractere pseudo / dev / null.
• Você não tem permissão para escrever em / dev / (o que seria necessário para substituir / dev / null)
• Permissão negada.

O segundo exemplo é muito mais fácil de ler. De sua saída:

drwx------  2 root   root    4096 Mar 11 21:04 .gvfs
drwx------  2 root   root    4096 Mar 11 21:04 dconf

Esses diretórios são de propriedade de root e não dão permissão para que ninguém os leia ou insira. find é exibido porque não tem permissão para entrar.

    

Answer 2

  

Existe alguma diretriz geral a seguir para saber "por que" recebo um erro de Permissão negada durante a execução de um comando específico?

A idéia geral é que esses diretórios não são de propriedade do usuário com o qual você costumava pesquisar e também não estão no grupo. Portanto, o comando informa que não é possível entrar nesse diretório para realizar sua descoberta. Dentro / home existem alguns arquivos que não pertencem ao usuário.

Você pode usar isto:

 find /home/ -uid 0

(ou um comando similar: ls -la| awk '{ if ( == "root") print }' ) para encontrar todos os arquivos em / home de propriedade do root. Os próprios arquivos não fornecerão um erro ao localizar, apenas diretórios, para que você possa expandi-los para find /home/ -type d -uid 0 ( -type f para apenas arquivos).

Quanto a este exemplo:

drwx------  2 root   root    4096 Mar 11 21:04 .gvfs
drwx------  2 root   root    4096 Mar 11 21:04 dconf

seu comando, nesse caso, deveria ter incluído sudo para evitar a mensagem, já que esses 2 não são de propriedade do seu nome de usuário e tanto o grupo quanto os outros são excluídos de r (ead). Então ...

sudo find . -inum 393222 -exec nano {} \;

Mas o aviso sobre a permissão em si é inofensivo. Você pode até mesmo suprimir mensagens de erro adicionando 2>/dev/null ao seu achado.

E sim, todos concordamos que qualquer comando precisa ser examinado antecipadamente. Há algumas coisas comuns para procurar: como rm ou mv , /dev/null , /dev/random e coisas como forkbombs (não dando exemplos disso :)).

    

Answer 3

Tudo depende do que o comando está fazendo. A lista é muito longa. Vamos dar o seu exemplo de cima.

Você está tentando usar nano para abrir um diretório chamado .gvfs . A menos que você seja root (via sudo ), você não poderá.

Por quê?

Veja as permissões de arquivo à esquerda.

O primeiro caractere é d . Isso significa que .gvfs é um diretório. Abrir um diretório em um editor de texto não vai te fazer muito bem, mas é possível do mesmo jeito.

Os próximos três caracteres são rwx . R = ler, W = escrever & amp; X = executar. Isso significa que o usuário root leu, escreveu e executou permissões nesse diretório.

Como sabemos que somente root tem essas permissões?

Geralmente, há 10 caracteres que você pode ver para uma permissão de arquivo. Nesse caso, eles são drwx------ .

Após o primeiro caractere, as permissões são lidas em blocos de 3. As três primeiras são permissões de proprietário, as próximas três são de grupo e as três finais são de nível mundial.

Assim, o diretório, como podemos ver, é de propriedade do usuário root e os atributos do grupo também são root , como pode ser visto pelo root root bit. Portanto, somente o usuário root tem permissão para fazer qualquer coisa com .gvfs . Qualquer outro usuário que seja membro do grupo root não tem permissões - como pode ser visto no segundo bloco de três permissões de arquivo: --- . O mesmo vale para qualquer outro usuário, independentemente da associação do grupo, como pode ser visto no terceiro bloco de três permisisons de arquivo: --- .

Se .gvfs tiver permissões de drwxrw-r-- , o seguinte será aplicado:

• rwx = o proprietário ( root ) do diretório leu, escreveu & amp; executar permissões neste diretório.

• rw- = qualquer usuário no grupo root leu, gravou permissões, mas não possui permissão de execução.

• r-- = qualquer outro usuário tem permissão somente para leitura. Nenhuma permissão de gravação ou execução.

Sempre que você receber um erro Permissão negada, precisará saber o que é você ou o comando que está executando, está tentando fazer.

Às vezes, apenas root tem permissão para executar o comando ou apenas root tem permissão para executar as instruções do comando que você está executando, como um usuário diferente está tentando fazer - como editar um arquivo de configuração do sistema.

Espero que isso não tenha te confundido ainda mais.