Início / computer / Perguntas / 1575590
Accepted
showkey
Asked: 2020-08-06 17:34:11 +0800 CST

Por que a expressão curinga não pode ser usada como um usuário não raiz?

  • 772

Estou usando uma expressão curinga para corresponder a um nome de arquivo.

Isso é o que acontece com um usuário normal não root:

debian@MiWiFi-R3-srv:~$ sudo ls  /var/log/apache2/*[0-9].gz
ls: cannot access '/var/log/apache2/*[0-9].gz': No such file or directory

E é isso que acontece depois que eu mudo para o usuário root sudo sue tento o mesmo comando:

root@MiWiFi-R3-srv:/home/debian# ls  /var/log/apache2/*[0-9].gz
/var/log/apache2/access.log.10.gz  /var/log/apache2/error.log.10.gz
/var/log/apache2/access.log.11.gz  /var/log/apache2/error.log.11.gz
/var/log/apache2/access.log.12.gz  /var/log/apache2/error.log.12.gz

Por que essa expressão curinga pode ser usada como root, mas não como um usuário normal não raiz?

bash shell

2 respostas

  1. Best Answer

    A /var/log/apache2/*[0-9].gzsubstring *[0-9]é manipulada pelo mecanismo de expansão do nome do caminho do shell. Não de sudonem ls. Da casca . Isso acontece antes sudoou lsmesmo começa.

    Para expandir /var/log/apache2/*[0-9].gzo shell, é necessário examinar o conteúdo do arquivo /var/log/apache2/. No meu Debian 10 as permissões são rwxr-x---, a propriedade é root:adm. Na verdade, o shell do root pode examinar o conteúdo, mas o shell de um usuário comum não pode.

    Portanto, o padrão é expandido para root, mas permanece textualmente para um usuário regular. Nem expanda o padrão e, eventualmente, o usuário regular (elevado) sudotenta listar informações sobre exatamente; não existe tal arquivo ou diretório.lsls/var/log/apache2/*[0-9].gz

    Isso deve funcionar para um usuário comum:

    sudo sh -c 'ls /var/log/apache2/*[0-9].gz'

    Nesse caso sudo, será executado elevado sh e esse shell expandirá o padrão com sucesso.

    (No começo eu pensei sudo -s …que faria isso, mas não .)

    • 33

  2. Ao contrário do Windows/DOS, globs são expandidos pelo shell antes de executar o comando em sistemas Unix. O shell, neste caso, está sendo executado com seu UID, não root, portanto, não pode ler esse diretório.

    O comportamento padrão no caso de não correspondência é passar a expressão glob literalmente. por exemplo, se você executar ls xyz*xyzem seu shell normal, verá ls: cannot access 'xyz*xyz': No such file or directoryfrom ls, porque recebeu essa string como um argumento.

    Assim como se você corresse ls '*'para passar *como uma string literal para ls. (A remoção de aspas também é tarefa do shell, portanto, um comando não pode dizer se seu argumento foi citado ou não.)

    Você pode alterar esse comportamento no bash, por exemplo, shopt -s failglobsignifica que o mesmo ls xyz*xyzcomando será fornecido bash: no match: xyz*xyz sem invocar lsnada. (Se você tivesse usado sudo, teria notado que ele não solicitou uma senha antes de receber essa mensagem de erro.)

    failglobproduz o mesmo erro "sem correspondência" ao tentar ler um diretório no qual você não tem permissão de leitura, infelizmente não avisando sobre o erro EPERM que o bash vai quando fez uma openchamada de sistema no diretório.bash: no match: /var/log/private/*

    (Há também shopt -s nullglob, onde uma expressão glob não correspondente é removida em vez de transmitida literalmente. Então, seu sudo ls /...*comando teria sido executado de forma confusa como sudo ls. Isso talvez seja útil para scripts em que você pode querer fazer *.gz *.tgz *.tarou algo assim, e não obter erros do falha na expansão. Provavelmente não é algo que você normalmente deseja para uso interativo.)

    Você pode usar shopt -u failglobou qualquer outra coisa para desativar essas opções em um shell, se configurá-las para experimentá-las.

    • 2

relate perguntas