Alterar permissões de arquivo funciona como root, mas não como sudo

Question

Eu tenho um problema muito estranho. Eu tenho alguns arquivos em um diretório grande que eu quero tornar legível por todos. Então eu tento isso:

sudo find readme* -not -perm -o+r -exec chmod +r {} \;

e consiga isto:

sudo: unable to execute /usr/bin/find: Success

Eu não sei porque diz sucesso, porque as permissões não foram alteradas. Eu verifiquei digitando isso:

find readme* -not -perm -o+r -exec ls -l {} \;

e obtenha algo como

-rw------- 1 root root 536871076 Nov 22 14:06 readme_20101122200429
-rw------- 1 root root 536871892 Nov 22 14:08 readme_20101122200642
-rw------- 1 root root 293458128 Nov 22 14:10 readme_20101122200859

como último recurso, tentei:

sudo chmod +r *

e obtivemos:

sudo: unable to execute /bin/chmod: Success

e novamente Sucesso realmente significa falhar. Então, desisti e entrei como root e tentei:

find readme* -not -perm -o+r -exec chmod +r {} \;

Desta vez funcionou. Por quê?

EDIT: / etc / sudoers se parece com:

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

##Me
user1   ALL=(ALL)       ALL

    

Answer 1

Eu não sei em qual versão de encontrar você está usando. Mas, geralmente, o primeiro argumento é o diretório onde encontrar, e se você quiser filtrar alguns nomes de arquivos, você tem que usar o argumento -name. Meu palpite será

sudo find . -name 'readme*' -not -perm -o+r -exec chmod +r {} \;

Não se esqueça de citar o padrão do nome do arquivo. Se você não fizer isso, o * será avaliado pelo shell e não será passado diretamente como um argumento. Isso pode explicar o comportamento estranho. Porque neste caso, provavelmente o shell tenta passar todos os nomes de arquivos correspondentes ao readme * como argumentos para o sudo.

    

Answer 2

Eu acho que você deveria usar:

sudo sh -c 'find readme* -not -perm -o+r -exec chmod +r {} \;'

Isso faz com que sudo execute o shell, que interpreta o argumento como -c como um script de shell. Usar aspas simples é mais simples - a menos que haja aspas simples no comando a ser executado. Nesse caso, cada citação única no comando é substituída por quatro caracteres - '\'' : quote, barra invertida, citação, citação.

No entanto, no contexto, não quero garantir que você não receba:

sudo: unable to execute /bin/sh: Success

O erro estranho provavelmente significa que uma chamada de função exec*() family retornou, mas o valor restante em errno foi zero. Isso não deveria acontecer - mas aparentemente aconteceu. O que acontece com:

sudo /bin/ls      # Or /usr/bin/ls if that's correct for your machine

Quando você verificou pela última vez a instalação sudo ? Quando você reinicializou pela última vez? Parece que há algo maluco no modo sudo é (errado) manipular os comandos para você.

O diretório que você está trabalhando no NFS está montado? A raiz geralmente tem privilégios mínimos em tais diretórios. Mas o erro deve ser da variedade EPERM (Sem permissão), não da variedade 'sucesso quando falhou'.