--Apple-Mail=_81980A43-FAA2-4108-A5C5-FB3167E62309
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Bonjour,
Le 18 févr. 2024 à 18:46, Bernard Bass <[email protected]> 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 <--
--Apple-Mail=_81980A43-FAA2-4108-A5C5-FB3167E62309
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Bonjour,<br class=""><div><br class=""><blockquote type="cite"
class=""><div class="">Le 18 févr. 2024 à 18:46, Bernard Bass <<a href="mailto:
[email protected]" class="">
[email protected]</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#929292" class="">
<div class="moz-text-html" lang="x-unicode"> Bonjour,<br class=""><p class="">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 ?<br class="">
echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers</p><div class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><div>
<br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#929292" class=""><div class="moz-text-html" lang="x-unicode"><p class=""><b class="">>> Je pense avoir mal compris, je n'aurais pas du
désactiver root, mais seulement supprimer le mot de passe </b><b class="">pour
ne pas conserver le hash du mot de passe root en mémoire.<br class="">
>> sudo passwd -d root</b></p><p class=""><b class=""><br class="">
</b></p><p class=""><b class="">################################</b><br class="">
<b class="">################################<br class="">
>> Il faudrait alors réactiver l'utilisateur root , pour
qu'il puisse gérer les tâches cron du système ( cron.daily ...
) :<br class="">
>> sudo passwd --unlock root</b><br class="">
<b class="">>> Affiche :<br class="">
>> passwd : déverrouiller le mot de passe créerait un
compte sans mot de passe.</b><br class="">
>> Vous devriez définir un mot de passe avec usermod -p
pour déverrouiller le mot de passe de ce compte.<br class="">
</p><p class=""><br class="">
>> passwd -S root<br class="">
>> root L 2024-01-03 0 99999 7 -1<br class="">
<b class="">>> Le compte reste verrouillé (L) après la commande
passwd --unlock root</b><br class="">
</p><p class=""><br class="">
>> <b class="">Définir un mot de passe avec usermod -p pour
déverrouiller</b> le mot de passe de ce compte (root)<br class="">
<b class="">>> Il est indiqué dans une documentation d'enlever le
mot de passe du compte root pour ne pas laisser le hash en
mémoire. :/<br class="">
<br class="">
<font color="#1a5fb4" class="">>> passwd root crérait / recrérait
un compte root sans mot de passe ? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<br class="">
>> 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.<br class="">
</font></b><br class="">
<b class="">################################<br class="">
</b><b class="">################################</b></p><p class=""><br class="">
</p><p class="">Même si on interdit la connexion directe sous « root », ce qui
peut se concevoir, <br class="">
</p><p class=""><b class="">>>Oui, j'ai désactivé la connexion à root depuis SSH.
<br class="">
>> Il me semble qu'il faille le faire pour le système
aussi ? # Sans supprimer le compte root pour autant ? # C'est
confus.</b></p><p class="">il n’empêche que certaines commande doivent être lancées avec
ces droits.<br class="">
>> Effectivement.<br class="">
<br class="">
<br class="">
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.</p><p class=""><b class="">>> Oui il est possible de modifier la crontab root
avec sudo crontab -e <br class="">
>> 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é.</b><br class="">
</p><p class=""><br class="">
</p><p class="">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 » !</p><p class=""><b class="">>> 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é. )</b><br class="">
>> sudo nano /etc/sudoers<br class="">
<br class="">
>> 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.<br class="">
>> Attention, tous les fichiers qui contiennent "~" ou "."
dans le nom ne seront pas lus !<br class="">
>> 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.<br class="">
<br class="">
>> Pour créer un nouveau fichier nommé "amis_sh", on
utilisera :<br class="">
>> sudo visudo /etc/sudoers.d/amis_sh<br class="">
>> sudo chmod 440 /etc/sudoers.d/amis_sh<br class="">
<br class="">
<b class="">>> Ajouter deux ligne pour le script sudoer à autoriser
:<br class="">
>> 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.<br class="">
>> amis_sh ALL=(ALL)
NOPASSWD:/home/amis_sh/test-crontab-sudo.sh</b></p><p class="">>> nano test-crontab-sudo.sh<br class="">
>> Ajouter les lignes suivantes :<br class="">
</p><p class="">>> !/bin/sh<br class="">
>> touch "/home/amis_sh/test-crontab-sudo-ok1"; # Un
fichier avec droits utilisateur est créé.<br class="">
>> su - amis_sh -c "touch test-crontab-sudo-user-ok"; # Un
fichier avec droits root est créé.<br class="">
>> touch "/home/amis_sh/test-crontab-sudo-ok2"; # Un
fichier avec droits utilisateur est créé.</p><p class="">>> Utiliser la crontab de l'utilisateur : crontab -e<br class="">
>> 55 12 * * * user=$(whoami) sudo
/home/amis_sh/test-crontab-sudo.sh >> updates.log
2>&1<br class="">
</p><p class=""><br class="">
</p><p class="">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 ;-)<br class="">
<b class="">>> Oui, Je suppose que l'on peut utiliser ici un nouvel
utilisateur gestionnaire avec les droits root.</b><br class="">
>> Le problème reste présent pour lancer les tâches
cron.daily si l'utilisateur root est désactivé.<br class="">
<br class="">
</p><p class="">Mention du paquet Debian super. <a class="moz-txt-link-freetext" href="
https://packages.debian.org/trixie/super">https://packages.debian.org/trixie/super</a>
paramétrable finement par /etc/super.tab <br class="">
<b class="">>> Je n'ai pas regardé cette possibilité.</b><br class="">
>> Je lis pour les droits setuid :<br class="">
</p><p class=""># Elever les droits setuid sur les scripts exécutés par cron
pour ne pas avoir à utiliser sudo :<br class="">
<b class="">>></b> <b class="">Cette méthode pour ne pas utiliser sudo
n'est pas recommandée</b> :<br class="">
# sudo chown root script.sh<br class="">
# sudo chmod 710 script.sh<br class="">
# sudo chmod u+s script.sh<br class="">
</p>
</div>
</div>
</div></blockquote></div><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space;
line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-
wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing:
0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform:
none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0,
0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div
dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-
break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><font face="Courier New" style="color: rgb(0, 0, 0); text-decoration: none;" class=""><font style="color: rgb(0, 0, 0); text-decoration: none;" class=""><font size="1"
class="">-- </font><br class=""><font size="1" class=""><span style="font-style: normal;" class="">Pierre Malard</span></font></font></font></div><div><font face="Courier New" style="color: rgb(0, 0, 0); text-decoration: none;" class=""><font style="
color: rgb(0, 0, 0); text-decoration: none;" class=""><font size="1" class=""><span style="font-style: normal;" class=""><br class=""></span></font></font></font><font face="Times" style="color: rgb(0, 0, 0); text-decoration: none;" class=""><i class="">&
nbsp; «Il vaut mieux passer à La Poste qu’à la postérité»</i><br class=""><span style="font-style: normal;" class="">
Alphonse Allais<br class=""></span></font><br class=""> <font face="Courier New" size="1" style="color: rgb(0, 0, 0); text-decoration: none;" class=""><span class="Apple-converted-space"> <
/span> |\ _,,,---,,_<br class=""> /,`.-'`' -. ;-;;,_<br class=""> |,4- ) )-,_. ,\ ( `'-'<br class=""> '---''(_/--' `-'\_) πr<br class=""><br class="">perl -e '$_=
q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'<br class="">- --> Ce message n’engage que
son auteur <--</font></div></div></div></div></div></div></div></div></div> </div>
<br class=""></body></html> --Apple-Mail=_81980A43-FAA2-4108-A5C5-FB3167E62309--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2
Comment: GPGTools -
http://gpgtools.org
iQIzBAEBCgAdFiEE0KHTJ+AWKhmI+acm/pSWHuad/BgFAmXSR+QACgkQ/pSWHuad /BjQ9Q/9EJk4iwSTzkc5lDybUfYL3X0TXVzHFNC5oZTRXHTCN8r9WCOTS/00/XQk SLl8JPCH2WKA56MeMFp7MzERZPeyispH2JR+CWP/dDC2AwiLIBGZL0NBq8JmXQSd RkcyESpeQAV7EiSgUXCtKXkP0VmpHMp1PcpujdK7uXoQdaAoUOMkkrKqdPdg5wwi Ss4eJbA8CGemhhUNFPRBBC1k+31DwRTaAuYatrXYvoC1ND6I9jnQ5jKF5aN8A/6+ NW+eJHZVnWzvZN4XJplPT+xsKV32Y/zwv6nfIUeLR1LiTa2+b7JJdsxRJLA1G1Ei OPHqMXSBsWJfl34BaewUfCDelnHB4dtKSl6i4c64RAZHEFJ4Agtf+M+9dyvESMl2 9b5zof7RQaqkWFsyvjkBhl4fpr0F+5vwroo/BEjQHwVPPpdh7lU+jNYxB14gvE1k BScy0HTwYennQf0nr0EXSD4is+gBsLXQlo5Q/czjOjdoDoOytNpVZ3JsO/52Udce 0IvagCDoh1PKm5+fc70Wf9kytg8nlQVTrSBOATX4do/gqEAc1UeEpaN4APgT/R1T C6buz7y3y71rJbIJQPABpGq19ITOPDsAe97dwR9T/aslmWP3LSlIdtjoYUOppidh NJ1r7GsytS8W9okXltfpdUc5q8D7Uigd80QKmQcfFfHLBBpM0CY=
=DwLm
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)