Bonjour, > Le 18 févr. 2024 à 18:46, Bernard Bass <bernard.b...@visionduweb.com> a écrit > : > > 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 > >
J’ai du louper des épisodes car je ne vois nulle part dans les réponses faites une mention laissant entendre qu’il fallait « disposer [l’utilisateur] de saisir son mot de passe ». C’est, à mon sens, une très mauvaise pratique à moins de limiter drastiquement les commandes laissées à cet usage. > >> 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 > <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 > -- Pierre Malard «Il vaut mieux passer à La Poste qu’à la postérité» Alphonse Allais |\ _,,,---,,_ /,`.-'`' -. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
