☰

Por que o sudo não consegue encontrar um comando que o usuário normal consegue?

tag-icon • tag-icon permissions sudo
Por que o sudo não consegue encontrar um comando que o usuário normal consegue?

Há um tempo atrás eu estava instalando o NPM e percebi que quando tentei executar o script shell de instalação usando sudo, ele gerou erros relacionados a alguns comandos que não foram encontrados. Porém, ao tentar executar o mesmo script sem sudo, tudo funcionou perfeitamente.

Sou um novo usuário do Linux, mas, pelo que entendi, as permissões e a visibilidade do sudo são um superconjunto do usuário normal.

Por que isso acontece?

Responder1

Pelo que entendi, as permissões e a visibilidade do sudo são um superconjunto do usuário normal.

Permissões, sim, mas não necessariamente visibilidade. A visibilidade das aplicações é regida pela PATHvariável ambiental

~$ printenv PATH
/home/vanadium/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/games

Quando um comando é digitado, o interpretador de comandos primeiro verifica se é um comando interno ou se o comando corresponde ao nome de um arquivo executável no disco. O sistema então pesquisa os diretórios listados PATHaté que um arquivo executável seja encontrado com um nome que corresponda ao comando.

Como você pode ver no exemplo, um usuário pode ter diretórios privados adicionais no arquivo PATH, pesquisados ​​somente quando esse usuário estiver emitindo o comando. Assim, sim, uma conta de usuário pode ter disponíveis comandos diferentes do rootusuário, ou seja, do administrador, função assumida quando você utiliza o sudocomando.

Ainda assim, as permissões de um executável determinam quem pode executar o arquivo. Desde que as permissões permitam, um executável sempre pode ser executado fornecendo o nome completo do caminho no prompt, por exemplo, /usr/bin/mountem vez de apenas o nome do arquivo, mount. E, de fato, rootsempre pode ser executado desde que o bit executável esteja definido, mesmo que seja apenas para o proprietário.

Responder2

Digamos que você queira executar um arquivo em seus scripts de diretório. você executaria:

myscript.sh

e o script funciona bem. Mas depois de executar o sudo, este é o erro que você recebe:

sudo: myscript.sh: file not found

Sempre que o sudo é usado, ele usa o caminho do usuário root. A solução para isso seria executar o comando desta forma:

sudo ./myscript.sh

Responder3

O shell (bash etc.) usa variáveis ​​​​diferentes no modo de usuário regular e no modo sudo. Basta verificar isso seguindo o procedimento:

# Plain user
printenv > env1
# Using sudo
sudo printenv > env2
# Comparison
diff env1 env2
# Alternative comparison using the GUI tool meld
meld env1 env2

Se o meld não estiver instalado, você poderá instalá-lo facilmente. É muito útil.

sudo apt-get update
sudo apt-get install meld

Diferentes conteúdos de variáveis ​​​​de usuário simples/sudo podem influenciar o comportamento do shell e a funcionalidade do script.

As permissões de acesso a arquivos também são diferentes.

Responder4

Na verdade, é um pouco mais complicado do que isso. Existem algumas definições que precisam existir no /etc/sudoers.

Os sinalizadores de controle que determinam o que acontece com o sudoambiente são: env_check, env_keepe env_reset.

Opágina de manual para sudoersfaz um bom trabalho explicando isso na seção "Ambiente de comando":

$ man --pager="less -p '^\ *Command environment'" sudoers

Em uma configuração pronta para uso do Ubuntu, o sinalizador definido para PATHé chamado secure_path(habilitado por padrão). O valor é usado no lugar do usuário PATHpara iniciar sudoporque env_resettambém está habilitado por padrão:

$ man sudoers | egrep "^\ *secure_path" -A4 | sed 's/^ *//'

secure_path   If set, sudo will use this value in place of the user's PATH environment variable. This option can be used to reset the PATH to a known good
value that contains directories for system administrator commands such as /usr/sbin.

Users in the group specified by the exempt_group option are not affected by secure_path.  This option is not set by default.

(Editar: a última linha acima refere-se a exempt_groupnão estar habilitado por padrão, não ao secure_path)

Você pode modificá-lo usando visudo(recomendado) ou exibi-lo:

$ sudo grep secure_path /etc/sudoers
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Outras vezes, os comandos são integrados ao bash (como echo) e não são um executável que você pode referenciar em uma PATHvariável. Estes são os momentos em que você precisa canalizar algum valor para um sudo bash -cououtras maneiras.

informação relacionada