Sudo não pode ver executáveis ligados simbolicamente no caminho

Question

No CentOS 7, instalei alguns executáveis em /opt/app-version/bin/executable . Esses executáveis têm as seguintes permissões:

rwxrwxr-x. 500 500

Propriedade de todos os diretórios no caminho /opt/app-version/bin/ é 500 500 - exceto /opt , que é root root .

Minha primeira pergunta: o que é esse 500 500 business? Como eu instalei os executáveis usando sudo , o proprietário e o grupo não devem ser root ?

Eu executei o seguinte comando como root para criar links simbólicos para os executáveis em /usr/local/bin/ :

ln /opt/app-version/bin/executable /usr/local/bin/executable --symbolic

Eu posso executar executable da linha de comando como um usuário comum, mas não como um usuário comum usando sudo .

Executando sudo executable retornando sh: executable: command not found .

A execução de sudo echo $PATH mostra que /usr/local/bin/ está em $PATH para ambientes sudo. (Ou é? Estou vendo o conteúdo de $PATH para o ambiente de super usuário, ou $PATH para o ambiente do usuário que chamou sudo ? O CentOS cria um novo ambiente para comandos executados com sudo , ou apenas executa o comando no ambiente do chamador?)

A execução de sudo ls -la /usr/local/bin/executable retorna uma listagem de executable em /usr/local/bin/ com a propriedade lrwxrwxrwx. 1 root root . (O ln --symbolic realmente cria links globalmente editáveis por padrão? Não é uma idéia horrível?) Meu entendimento é que isso mostra sudo deve ser capaz de executar executable .

O que estou perdendo?

    

Answer 1

Olhando primeiro para o 500 500 , se você restaurar de um arquivo tar (entre outros), o proprietário e o grupo serão preservados do sistema em que o arquivo foi criado: Suponho que o instalador faça isso, e se o usuário ou grupo restaurado não existir em seu sistema, o valor numérico será exibido.

Olhando agora para o PATH , eu reproduzi isso no Ubuntu, e parece que sudo modifica PATH : no seu comando sudo echo $PATH a variável PATH foi expandida no shell original antes de chamar% código%. Existe um arquivo sudo com uma entrada /etc/sudoers , e isso parece ser o que é usado.

Se você usar "defaults secure_path="..." , terá uma ideia melhor do sudo sh -c 'echo $PATH' que está sendo usado. Observe que usei deliberadamente PATH em vez de sh para ignorar alguns dos arquivos de inicialização, o que pode mudar as coisas, embora bash tenha, claro, alguns dos seus próprios.

No Ubuntu, a linha sh contém secure_path , mas o CentOS pode ser diferente (ambos são derivados do Debian, mas de acordo com /user/local/bin o SELinux pode sobrescrever algumas entradas). Tanto quanto eu posso ver, você tem pelo menos quatro opções: -

• Modifique man sudoers para incluir '/ usr / local / bin'.
• Coloque o link em um dos diretórios definidos em secure_path .
• Use secure_path em vez de su -c "{command} {parameters}" .
• Use sudo {command} {parameters} para obter uma raiz sudo -s com a mesma inicialização de bash do shell original e, em seguida, chame seu executável de lá e saia depois.

Também encontrei muitas discussões e outras possíveis soluções aqui .