Судо не працює над певними командами

У sudoDebian 8. у мене досить дивна проблема з Debian 8. Користувачі не можуть виконувати деякі команди в /etc/sudoers.d. Я використовую Chef для розповсюдження конфігурацій, тому всі файли створюються автоматично.

Приклад:

Цей конфігуратор працює чудово

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

І це не вдається:

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.

Що може бути не так?

Діагностика:

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

— Лайн Івакура
джерело

Відповіді:

Проблема - крапка в update-rc.d(в /etc/sudoers.d/update-rc.d); від man sudo:

Директива #includedir може бути використана для створення каталогу sudo.d, в який менеджер системних пакетів може скидати правила sudoers як частину установки пакета. Наприклад, наведено:
#includedir /etc/sudoers.d
sudo прочитає кожен файл у /etc/sudoers.d, пропускаючи імена файлів, які закінчуються на ~ або містять a. символу, щоб уникнути проблем з тимчасовими / резервними файлами менеджера пакунків або редактора.

— MadHatter
джерело

Це 2 сумнівні дизайнерські рішення в судорах. Використання #як коментаря та як частини директиви, а також ігнорування файлів. Цікаво (дратівливо) visudo -f some.file не попереджає, що, ймовірно, його ігнорують при виході. Квітковий альбатрос може бути заспокоєний простим результатом.

— користувач9517

@istheEnglishway повністю згоден. Але допитливий альбатрос залишається певним.

— MadHatter

Ігнорування файлів з ~ (або, справді, з деякими розширеннями) насправді дуже гарна ідея, оскільки ви, звичайно , не хочете, щоб стара конфігурація у файлі резервної копії була активна після редагування. І ви, мабуть, не хочете вручну перевіряти, чи редактор на цій машині також залишив резервний файл. Хоча, звичайно, це можна зробити, включивши лише файли з розширенням з білого списку (наприклад *.cf), але тоді можливо, що функція буде додана згодом, і якийсь користувач все одно скаржиться на те, що змушений використовувати розширення набору.

— ilkkachu

Що стосується хеш-знаку, який використовується як у коментарях, так і в директивах щодо включення, хтось до того, щоб перевірити, чи є зворотна відсталість сумісності?

— ilkkachu

Спробуйте запустити, sudo -llщоб отримати список команд / конфігурацій, застосовних для вашого користувача.

Якщо (як би це було так) ваш пункт update-rc.d не відображається, ви можете розглянути коригування рецептів шеф-кухаря для розгортання одного файлу sudoers.d на користувача, а не кількох.

Ви також можете врахувати, чи може бути гарантованим груповий файл судерів.

Відповіді на це питання допоможуть: /ubuntu/246455/how-to-give-nopasswd-access-to-multiple-commands-via-sudoers

— iwaseatenbyagrue
джерело