Bonjour,
Puis-je savoir à quoi sert de désactiver le compte root si
c'est pour donner les pleins pouvoirs à un autre compte, en le
dispensant de saisir son mot de passe lorsqu'il utilise la
commande sudo ?
echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
>> Je pense avoir mal compris, je n'aurais pas du
désactiver root, mais seulement supprimer le mot de passe pour
ne pas conserver le hash du mot de passe root en mémoire.
>> sudo passwd -d root
################################
################################
>> Il faudrait alors réactiver l'utilisateur root , pour
qu'il puisse gérer les tâches cron du système ( cron.daily ...
) :
>> sudo passwd --unlock root
>> Affiche :
>> passwd : déverrouiller le mot de passe créerait un
compte sans mot de passe.
>> Vous devriez définir un mot de passe avec usermod -p
pour déverrouiller le mot de passe de ce compte.
>> passwd -S root
>> root L 2024-01-03 0 99999 7 -1
>> Le compte reste verrouillé (L) après la commande
passwd --unlock root
>> Définir un mot de passe avec usermod -p pour
déverrouiller le mot de passe de ce compte (root)
>> Il est indiqué dans une documentation d'enlever le
mot de passe du compte root pour ne pas laisser le hash en
mémoire. :/
>> passwd root crérait / recrérait
un compte root sans mot de passe ?
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> Aucun hash de mot de passe ne serait alors conservé
en mémoire et le compte root serait utilisable par le
système pour utiliser cron.
################################
################################
Même si on interdit la connexion directe sous « root », ce qui
peut se concevoir,
>>Oui, j'ai désactivé la connexion à root depuis SSH.
>> Il me semble qu'il faille le faire pour le système
aussi ? # Sans supprimer le compte root pour autant ? # C'est
confus.
il n’empêche que certaines commande doivent être lancées avec
ces droits.
>> Effectivement.
du coup, pour modifier le crontab root, rien n’empêche
d’utiliser un sudo pour prendre ponctuellement ces droits pour
modifier le crontab root.
>> Oui il est possible de modifier la crontab root
avec sudo crontab -e
>> Les tâches ne seront pas lancées et resteront en
erreur "Authentication failure" avec l'utilisateur root
désactivé et le mot de passe expiré.
Dans le même sujet si une tâche n’a pas besoin des droits root
rien n’empêche d’utiliser un crontab « utilisateur » !
>> Oui, il faut autoriser les scripts depuis
"/etc/sudoers.d" mais les tâches systèmes ( cron.daily ... ne
sont pas lancées si l'utilisateur root est désactivé. )
>> sudo nano /etc/sudoers
>> Préférer le dossier "/etc/sudoers.d" : il sert à
stocker des fichiers déclaratifs pour sudoers qui seront lus en
complément du fichier sudoers.
>> Attention, tous les fichiers qui contiennent "~" ou "."
dans le nom ne seront pas lus !
>> Organiser les règles par fichier plutôt que de tout
centraliser dans le même fichier : le fichier sudoers sera
toujours lu, dans tous les cas.
>> Pour créer un nouveau fichier nommé "amis_sh", on
utilisera :
>> sudo visudo /etc/sudoers.d/amis_sh
>> sudo chmod 440 /etc/sudoers.d/amis_sh
>> Ajouter deux ligne pour le script sudoer à autoriser
:
>> amis_sh ALL=(ALL:ALL) ALL # Pas certain qu'il faille
utiliser cette ligne. J'ai testé sans, il me semble que cela
ne fonctionne pas.
>> amis_sh ALL=(ALL)
NOPASSWD:/home/amis_sh/test-crontab-sudo.sh
>> nano test-crontab-sudo.sh
>> Ajouter les lignes suivantes :
>> !/bin/sh
>> touch "/home/amis_sh/test-crontab-sudo-ok1"; # Un
fichier avec droits utilisateur est créé.
>> su - amis_sh -c "touch test-crontab-sudo-user-ok"; # Un
fichier avec droits root est créé.
>> touch "/home/amis_sh/test-crontab-sudo-ok2"; # Un
fichier avec droits utilisateur est créé.
>> Utiliser la crontab de l'utilisateur : crontab -e
>> 55 12 * * * user=$(whoami) sudo
/home/amis_sh/test-crontab-sudo.sh >> updates.log
2>&1
Enfin, si on souhaite mieux gérer tout ça on peut utiliser
/etc/cron.d où on indique l’utilisateur à utiliser pour lancer
la commande souhaitée… mais il faut avoir les droits « root »
pour créer cette entrée ;-)
>> Oui, Je suppose que l'on peut utiliser ici un nouvel
utilisateur gestionnaire avec les droits root.
>> Le problème reste présent pour lancer les tâches
cron.daily si l'utilisateur root est désactivé.
Mention du paquet Debian super. https://packages.debian.org/trixie/super
paramétrable finement par /etc/super.tab
>> Je n'ai pas regardé cette possibilité.
>> Je lis pour les droits setuid :
# Elever les droits setuid sur les scripts exécutés par cron
pour ne pas avoir à utiliser sudo :
>> Cette méthode pour ne pas utiliser sudo
n'est pas recommandée :
# sudo chown root script.sh
# sudo chmod 710 script.sh
# sudo chmod u+s script.sh