sudo nie działa na niektórych poleceniach

Mam dość dziwny problem z sudoDebianem 8. Użytkownicy nie mogą wykonywać niektórych poleceń w /etc/sudoers.d. Używam Chef do dystrybucji konfiguracji, więc wszystkie pliki są generowane automatycznie.

Przykład:

Ta konfiguracja działa dobrze

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

I to się nie udaje:

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.

Co może być nie tak?

Diagnostyka:

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
źródło

Odpowiedzi:

Problemem jest kropka w update-rc.d( cal /etc/sudoers.d/update-rc.d); z man sudo:

Dyrektywy #includedir można użyć do utworzenia katalogu sudo.d, do którego menedżer pakietów systemowych może upuszczać reguły sudoers w ramach instalacji pakietu. Na przykład biorąc pod uwagę:
#includedir /etc/sudoers.d
sudo odczyta każdy plik w /etc/sudoers.d, pomijając nazwy plików, które kończą się na ~ lub zawierają a. znak, aby uniknąć problemów z menedżerem pakietów lub edytorem plików tymczasowych / zapasowych.

— Szalony Kapelusznik
źródło

To 2 wątpliwe decyzje projektowe w sudoers. Używanie #jako komentarza i jako część dyrektywy oraz ignorowanie plików. Co ciekawe (irytujące) visudo -f some.file nie ostrzega, że można go zignorować przy wychodzeniu. Querulous albatross można uspokoić prostym głosowaniem.

— user9517,

@istheEnglishway całkowicie się zgadza. Ale kłótliwy albatros pozostaje kłopotliwy.

— MadHatter

Ignorowanie plików z ~ (a nawet tymi z niektórymi rozszerzeniami) jest w rzeczywistości bardzo dobrym pomysłem, ponieważ zdecydowanie nie chcesz, aby stara konfiguracja w pliku kopii zapasowej była aktywna po edycji. Prawdopodobnie nie chcesz ręcznie sprawdzać, czy edytor na tym komputerze zostawił plik kopii zapasowej. Oczywiście można to zrobić, dołączając tylko pliki z rozszerzeniem z białej listy (np. *.cf), Ale może się zdarzyć, że funkcja została później dodana, a niektórzy użytkownicy i tak narzekaliby na zmuszenie do korzystania z ustawionego rozszerzenia.

— ilkkachu

Co do znaku skrótu używanego zarówno w komentarzach, jak i w dyrektywach dołączających, ktoś może sprawdzić, czy zgodność wsteczna również jest tego przyczyną?

— ilkkachu

Spróbuj uruchomić, sudo -llaby uzyskać listę poleceń / konfiguracji odpowiednich dla użytkownika.

Jeśli (jak się wydaje), twoja klauzula update-rc.d nie pojawia się, możesz rozważyć dostosowanie przepisów szefa kuchni, aby wdrożyć pojedynczy plik sudoers.d na użytkownika, a nie kilka.

Możesz także rozważyć, czy plik sudoers związany z grupą może być uzasadniony.

Odpowiedzi na to pytanie mogą pomóc: /ubuntu/246455/how-to-give-nopasswd-access-to-multiple-commands-via-sudoers

— iwaseatenbyagrue
źródło