Por que o sistema possui /etc/sudoers.d? Como devo editá-lo?

Na última vez, perguntei sobre o risco desses (em / etc / sudoers):

    user_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
    %group_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Enquanto eu pensava sobre esse problema, encontrei o diretório /etc/sudoers.d . Os arquivos no diretório devem ter funções semelhantes a / etc / sudoers (o que significa que os scripts acima ainda são problemáticos, mesmo em /etc/sudoers.d), e no entanto, um artigo disse que não devemos usar o diretório porque não podemos visudoeditar arquivos em isto. Ou seja, perdemos o direito de usar sudose cometermos um erro no diretório.

Se isso é verdade, por que temos o /etc/sudoers.d ? Ou temos uma boa maneira de editar arquivos em /etc/sudoers.d ?

As alterações feitas nos arquivos /etc/sudoers.dpermanecem em vigor se você atualizar o sistema. Isso pode impedir o bloqueio do usuário quando o sistema é atualizado. O Ubuntu tende a gostar desse comportamento. Outras distribuições também estão usando esse layout.

Foi minha experiência que as regras sobre os arquivos neste diretório são mais flexíveis do que para /etc/sudoers. Isso inclui:

• Erros no arquivo não causaram sudofalha. No entanto, o arquivo foi ignorado.
• As regras de permissão parecem menos rigorosas. Permite que o grupo ou outro aplicável leia o arquivo. Não acredito que isso fosse possível /etc/sudoers. As permissões de gravação devem ser restritas rootpara manter a segurança. A versão atual do Ubuntu do sudo permite permissões de leitura para grupos ou outros. (Esse recurso permite que o acesso ao sudo seja auditado usando sem a necessidade de acesso root.)

O visudocomando é padronizado apenas como /etc/sudoers. Ele editará e verificará qualquer arquivo que você especificar com a -fopção Eu uso esse recurso para editar arquivos que serão automaticamente instalados como /etc/sudoersou no /etc/sudoders.d. No entanto, definições de outros arquivos podem não ser encontradas. É melhor tornar o arquivo independente.

A capacidade de ter arquivos independentes torna simples para um aplicativo habilitar o sudorecurso na instalação e removê-los quando não estiver instalado. Ferramentas de configuração automatizada também podem usar esse recurso.

Eu usei esse recurso para isolar as alterações necessárias para conceder acesso a grupos de usuários específicos em sistemas específicos.

Sim, você pode usar visudopara editar esses arquivos. Tudo o que você precisa fazer é especificar o nome do arquivo que você deseja editar com a -fopção Por exemplo:

visudo -f /etc/sudoers.d/somefilename

Ou, se necessário:

sudo visudo -f /etc/sudoers.d/somefilename

Documentação

De man visudo:

-f sudoers
Especifique e alterne o local do arquivo dos sudoers. Com esta opção, o visudo editará (ou verificará) o arquivo sudoers de sua escolha, em vez do padrão / etc / sudoers. O arquivo de bloqueio usado é o arquivo de sudoers especificado com ".tmp" anexado a ele. Somente no modo somente verificação, o argumento para -f pode ser "-", indicando que os sudoers serão lidos a partir da entrada padrão.

Em suma:

1. Sintaxe: Ambos visudoe visudo -f executam a mesma verificação de sintaxe .

2. Permissões / Propriedade: como um recurso adicionado para auxiliar a administração de sistemas grandes , os arquivos editados em visudo -fnão são verificados quanto à propriedade ou permissões: isso permite a verificação de sintaxe de um arquivo offline ou como parte de um sistema de controle de revisão.

Por que usar /etc/sudoers.d/

Normalmente, /etc/sudoersestá sob controle do gerenciador de pacotes da sua distribuição. Se você fez alterações nesse arquivo e o gerenciador de pacotes deseja atualizá-lo, será necessário inspecionar manualmente as alterações e aprovar como elas são mescladas na nova versão. Ao colocar suas alterações locais em um arquivo no /etc/sudoers.d/diretório, você evita esta etapa manual e as atualizações podem prosseguir automaticamente.

Quando sudoignora um arquivo /etc/sudoers?

Se o seu /etc/sudoersarquivo contiver a linha:

#includedir /etc/sudoers.d

em seguida, sudoirá ler arquivos no diretório /etc/sudoers.d.

As exceções são:

1. Arquivos cujos nomes terminam em ~
2. Arquivos cujos nomes contêm um .caractere

Isso é feito (a) para conveniência dos gerenciadores de pacotes e também (b) para que os arquivos de backup dos editores sejam ignorados.

por que temos o /etc/sudoers.d?

Porque é mais fácil para ferramentas automatizadas (como Chef ou Puppet) soltar arquivos individuais nesse diretório, em vez de fazer alterações /etc/sudoers, o que pode ser frágil.

Os arquivos /etc/sudoers.dsão (com efeito) concatenados. Você verá várias outras instâncias desse padrão em /etc, como /etc/cron.de /etc/logrotate.d.

Outro benefício de usar visudo -fcomo mencionado em algumas respostas é que existe uma opção correspondente -cou --checkque verifica se você não possui informações inválidas em um arquivo sudoers.d ou em qualquer outro arquivo que você queira colocar em sudoers.d. Isso é MUITO útil nos casos mencionados com ferramentas automatizadas, pois você pode executar, por exemplo,

sudo visudo -c -q -f /home/myuser/mysudoers && \
sudo chmod 600 /home/myuser/mysudoers && \
sudo cp /home/myuser/mysudoers /etc/sudoers.d/mysudoers

Isso verifica silenciosamente o arquivo (sem saída devido a -q) e somente se isso NÃO retornar um erro (saída 1 significa um arquivo de sudoers inválido), ele copiará o arquivo para sudoers.d, dessa forma, você poderá criar o arquivo e trabalhe nele sem precisar sudo visudo -f /etc/sudoers.d/myfilecorrigi- lo da primeira vez (o uso deve ser bem-sucedido ou ele descarta o conteúdo se você não o corrigir).

Além disso, uma palavra de cautela sobre essas declarações das outras respostas.

Minha experiência foi de que as regras nos arquivos deste diretório são mais flexíveis que as do / etc / sudoers. Isso inclui:

Erros no arquivo não causaram falha no sudo. No entanto, o arquivo foi ignorado. As regras de permissão parecem menos rigorosas. Eu permito que o grupo aplicável leia o arquivo. Eu não acredito que isso seja possível com o / etc / sudo.

Os arquivos em /etc/sudoers.d precisam seguir a mesma sintaxe que os / etc / sudoers, porque, por baixo das coberturas, o sistema simplesmente concatena todos os arquivos com o último em "vitória" se houver várias entradas para a mesma cenário singular.

Se as permissões estiverem horrivelmente incorretas (graváveis ​​em todo o mundo) nos arquivos em /etc/sudoers.d/, elas serão ignoradas. Isso pode ter causado o esquecimento dos arquivos inválidos; caso contrário, você poderá violar seriamente o sudocomando com um sudoers inválido. d arquivo com permissões corretas.

Você pode permitir que os arquivos do sudoers sejam legíveis mundialmente, se você acidentalmente permitir 'other' a permissão de gravação necessária para sudo como outro usuário ou a partir de um terminal raiz, execute este comando. Isso também pode ser interrompido se o arquivo pertencer a alguém que não seja root: root.

sudo chmod 644 /etc/sudoers.d/mysudoers
sudo chown root:root /etc/sudoers.d/mysudoers

Acabei de confirmar que, se eu executar, chmod o+w /etc/sudoers.d/vagrantnão posso mais usar o sudo como usuário vagante, ele solicita minha senha e falha.

Quando corri sudo -lpara exibir as permissões de comando aplicadas como outro usuário sudo válido, também recebi um aviso sobre as permissões de arquivo. Este é o mesmo comando que eu usei para confirmar que o usuário 'vagrant' perdeu o sudo quando apliquei o+wpermissões ao arquivo, concedendo a ele permissões de sudo.

Apenas um pequeno complemento para qualquer resposta geral ... nenhuma das outras respostas resolveu meu problema, que era essa ordem.

Se suas linhas funcionarem em sudoers, mas não em sudoers.d, tente mover o #include, ou altere a ordem dos arquivos sudoers.d (prefixando um número). Parece que a coisa mais específica deve ser a primeira no arquivo.

Eu tinha algo como:

somebody ALL=(ALL): somecommand
somebody ALL=(someoneelse) NOPASSWD: somecommand

E o segundo não teve efeito porque o primeiro já correspondia. NOPASSWD não é uma condição, mas uma maneira de modificar a ação.

E não era óbvio porque não estava em um único arquivo, devido ao diretório sudoers.d.