sudo não funciona em certos comandos

Eu tenho um problema bastante estranho sudono Debian 8. Os usuários não podem executar alguns dos comandos no /etc/sudoers.d. Eu uso o Chef para distribuir configurações, para que todos os arquivos sejam gerados automaticamente.

Exemplo:

Esta configuração funciona bem

root@server:~# cat /etc/sudoers.d/nginx 
# This file is managed by Chef.
# Do NOT modify this file directly.

user  ALL=(root) NOPASSWD:/usr/sbin/nginx

E isso falha:

root@server:~# cat /etc/sudoers.d/update-rc.d 
# This file is managed by Chef.
# Do NOT modify this file directly.

user  ALL=(root) NOPASSWD:/usr/sbin/update-rc.d

user@www42:~$ sudo update-rc.d 
[sudo] password for user: 
Sorry, user user is not allowed to execute '/usr/sbin/update-rc.d' as root on server.

O que pode estar errado?

Diagnóstico:

Mar  5 12:12:51 server sudo:    user : command not allowed ; TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/sbin/update-rc.d
Mar  5 12:14:25 www42 su[1209]: pam_unix(su:session): session closed for user user

root@server:~# sudo --version
Sudo version 1.8.10p3
Configure options: --prefix=/usr -v --with-all-insults --with-pam --with-fqdn --with-logging=syslog --with-logfac=authpriv --with-env-editor --with-editor=/usr/bin/editor --with-timeout=15 --with-password-timeout=0 --with-passprompt=[sudo] password for %p:  --disable-root-mailer --with-sendmail=/usr/sbin/sendmail --with-rundir=/var/lib/sudo --mandir=/usr/share/man --libexecdir=/usr/lib/sudo --with-sssd --with-sssd-lib=/usr/lib/x86_64-linux-gnu --with-selinux --with-linux-audit
Sudoers policy plugin version 1.8.10p3
Sudoers file grammar version 43

— Lain Iwakura
fonte

Respostas:

O problema é o ponto em update-rc.d(in /etc/sudoers.d/update-rc.d); de man sudo:

A diretiva #includedir pode ser usada para criar um diretório sudo.d no qual o gerenciador de pacotes do sistema pode inserir regras de sudoers como parte da instalação do pacote. Por exemplo, dado:
#includedir /etc/sudoers.d
O sudo lerá cada arquivo em /etc/sudoers.d, ignorando os nomes de arquivos que terminam em ~ ou contêm a. caráter para evitar causar problemas com o gerenciador de pacotes ou editor / arquivos de backup temporários.

— Chapeleiro Louco
fonte

São duas decisões de design questionáveis em sudoers. Usando #como comentário e como parte de uma diretiva, além de ignorar arquivos. Curiosamente (irritante) visudo -f some.file não avisa que é provável que seja ignorado ao sair. Albatroz querulous pode ser acalmado por um simples voto positivo.

— user9517

@istheEnglishway concorda completamente. Mas o albatroz-de-cerco continua sendo deplorável.

— MadHatter

Ignorar arquivos com um ~ (ou, de fato, aqueles com algumas extensões) é realmente uma boa ideia, pois você definitivamente não deseja que a configuração antiga em um arquivo de backup seja ativada após a edição. E você provavelmente não deseja verificar manualmente se o editor nessa máquina também deixou um arquivo de backup. Embora, é claro, isso possa ser feito incluindo apenas os arquivos com uma extensão da lista de permissões (por exemplo *.cf), mas pode ser que o recurso tenha sido adicionado posteriormente e algum usuário reclamará de qualquer maneira sobre ser forçado a usar uma extensão definida.

— ilkkachu

Quanto ao sinal de hash sendo usado nos comentários e nas diretivas de inclusão, alguém pode verificar se a compatibilidade com versões anteriores também é o motivo?

— ilkkachu

Tente executar sudo -llpara obter uma lista dos comandos / configurações aplicáveis ao seu usuário.

Se (como parece ser o caso) sua cláusula update-rc.d não aparecer, considere ajustar suas receitas de chef para implantar um único arquivo sudoers.d por usuário, em vez de vários.

Você também pode considerar se um arquivo de sudoers relacionados ao grupo pode ser garantido.

As respostas desta pergunta podem ajudar: /ubuntu/246455/how-to-give-nopasswd-access-to-multiple-commands-via-sudoers

— iwaseatenbyagrue
fonte