Como os caminhos de execução relativos funcionam através do sudo

Question

Eu tenho um problema específico que trouxe algumas questões gerais.

O problema específico:

Eu tenho uma regra de sudoers aplicada a um grupo de usuários um pouco restritos. A regra em questão é %pusers ALL=(ALL) NOPASSWD: /bin/vi /etc/httpd/conf/* . Um usuário gostaria de cd /etc/httpd/conf e, em seguida, sudo vi httpd.conf (ou sudo vi ./httpd.conf ). Atualmente, o sudoers não permite isso, mas permitirá executar o vi no caminho absoluto: sudo vi /etc/httpd/conf/httpd.conf . Presumo que o caminho relativo não esteja sendo traduzido para o caminho completo antes do sudo verificar se ele é permitido, mas não sei exatamente por que ou como eu poderia contornar isso.

Estou trabalhando especificamente com o RHEL7 e não testei isso em outros sistemas * nix, embora espere ver um comportamento semelhante.

As perguntas gerais:

1. Como o sudo manipula os caminhos relativos passados a ele no lado execução , como no exemplo acima? (Caminhos de comando não relativos, caminhos relativos contra os quais um comando é executado).
2. Como um sudo pode reconhecer / traduzir o caminho de execução relativo de um comando ao verificar as regras dos sudoers?

Answer 1

Dar ao usuário regular sudo acesso a um editor como vi ou vim é arriscado. Veja esta pergunta para um em - explicação detalhada .

Com uma versão moderna de sudo , você pode especificar em sudoers :

%pusers ALL=(ALL) sudoedit /etc/httpd/conf/*

Em seguida, os usuários podem especificar o editor escolhido usando as variáveis de ambiente VISUAL ou EDITOR (como de costume) e, em seguida, usar

$ sudoedit /etc/httpd/conf/httpd.conf

ou

$ cd /etc/httpd/conf
$ sudoedit httpd.conf

Em vez de sudoedit , sudo -e também pode ser usado.

O sudo moderno reconhece sudoedit como um comando embutido em sudo e, quando você o usa, sudo entende que os argumentos devem ser nomes de caminho dos arquivos a serem editados (apenas) e, em seguida, nomes de caminho relativos tornam-se possíveis.

Em um caso geral (= quando não estiver usando a palavra-chave sudoedit ), sudo não presumirá saber nada sobre os parâmetros de comando, portanto, se você especificar um comando com parâmetros específicos no arquivo sudoers , apenas correspondência de strings "mudo" é possível.

Estritamente falando, você nem precisa mesmo de sudo para conceder acesso aos arquivos de configuração do Apache. O Apache não se importa particularmente com as permissões do arquivo de configuração, desde que o próprio Apache possa lê-las (e se o Apache usar portas < 1024, ele normalmente inicia como root, portanto, a leitura de arquivos não é um problema). Então, como você já tem um grupo, pode fazer isso:

 chgrp -R pusers /etc/httpd/conf
 chmod g+rws /etc/httpd/conf
 chmod g+rw /etc/httpd/conf/* 

O RHEL7 até usa o sistema "usergroups" por padrão, portanto os valores de umask dos usuários já devem ser 002 ou 007. Se isso for verdade, essas configurações únicas simples são tudo o que você precisa para que seus usuários gravem acesso aos arquivos de configuração do Apache. Seus usuários podem até criar novos arquivos no diretório de configuração e obter automaticamente a propriedade e as permissões de grupo corretas.

Na verdade, a maneira mais provável de atrapalhar acidentalmente as permissões dos arquivos de configuração nesse esquema seria adicionar novos arquivos a ele como root: o usuário root geralmente tem umask sem o bit de gravação de grupo (tradicionalmente 022 ou mais restrito 077), e o poder root também pode truncar o bit setgid nos diretórios.

Você pode ter que aprender alguns novos hábitos, mas, neste caso, desaprender "você deve ser root para configurar o Apache" pode realmente ser uma coisa boa. (E se você acha que sudo fornece mais trilha de auditoria, então realmente considere colocar os arquivos de configuração sob o Git ou algum outro sistema de controle de versão.)