CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF /

sudo sans mot de passe limité à une commande

Une règle NOPASSWD placée dans /etc/sudoers.d autorise une commande précise sans mot de passe, à condition que cette commande soit désignée par son chemin absolu. Sur Debian 13, la ligne marie ALL = (root) NOPASSWD: /usr/bin/systemctl restart nginx supprime l’invite [sudo] password for marie sans élargir ses droits ailleurs. Deux détails annulent la règle sans erreur de syntaxe : un nom de fichier contenant un point, et un chemin qui ne correspond pas au binaire installé.

Sommaire
  1. NOPASSWD n’ouvre qu’une commande, et le chemin absolu fait partie de la règle
  2. Quatre étapes mènent de command -v à un sudo -l qui confirme la règle
  3. Une règle ignorée produit trois messages différents selon l’origine du problème
  4. Portée, chemins exigés et utilisateurs visés changent selon la forme de la ligne
  5. Le cache d’authentification, le groupe et le terminal décident de l’effet réel
  6. Sources

NOPASSWD n’ouvre qu’une commande, et le chemin absolu fait partie de la règle

La règle NOPASSWD du fichier sudoers dissocie l’autorisation de l’authentification : elle accorde la commande et supprime la demande de mot de passe pour cette seule commande. La page de manuel sudoers(5) écrit qu’avec l’entrée ray rushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm, l’utilisateur ray exécute ces trois binaires en root sans s’authentifier. Le tag NOPASSWD porte sur les commandes qui le suivent dans la liste, et le tag PASSWD annule cet effet pour la suite. Une commande se désigne par un nom de fichier pleinement qualifié : sudo compare la chaîne inscrite dans sudoers au chemin réel du binaire, et un nom court comme systemctl ne correspond à rien. Le mode 0440 est le mode par défaut du fichier sudoers, lisible par le propriétaire et le groupe, inscriptible par personne.

Trois écritures couvrent l’essentiel : une commande, un alias de plusieurs chemins, une ligne visant un groupe.

marie ALL = (root) NOPASSWD: /usr/bin/systemctl restart nginx
%sudo ALL = (root) NOPASSWD: /usr/bin/systemctl restart nginx
Cmnd_Alias NETTOYAGE = /usr/bin/apt-get update, /usr/bin/apt-get upgrade
marie ALL = (root) NOPASSWD: NETTOYAGE

Un fichier déposé dans /etc/sudoers.d rejoint les autres réglages d’administration d’une machine Linux, et sudo le lit à la place exacte où la ligne @includedir apparaît dans /etc/sudoers.

Quatre étapes mènent de command -v à un sudo -l qui confirme la règle

La procédure tient en quatre gestes : relever le chemin réel de la commande, ouvrir un fichier dédié avec visudo, écrire la ligne, puis vérifier. Ces quatre étapes se font dans cet ordre, parce que visudo refuse d’enregistrer un fichier dont la syntaxe est fausse et qu’aucune vérification sérieuse n’est possible avant de connaître le chemin exact du binaire. Le nom du fichier compte autant que son contenu : les fichiers de /etc/sudoers.d sont lus dans l’ordre lexical et ceux dont le nom contient un point sont ignorés, ce que la page de manuel sudoers(5) indique explicitement. La page de manuel visudo(8) rappelle que visudo n’édite pas les fichiers d’un répertoire @includedir sauf si l’un d’eux contient une erreur, d’où l’usage de l’option -f.

  1. Relever le chemin absolu. 
    command -v systemctl

    Le terminal affiche /usr/bin/systemctl. Si la réponse commence par /bin/, c’est ce chemin-là qu’il faut recopier dans sudoers.

  2. Ouvrir le fichier de règles. 
    sudo visudo -f /etc/sudoers.d/90-nginx-restart

    L’éditeur s’ouvre sur un tampon vide et affiche en bas de fenêtre le fichier /etc/sudoers.d/90-nginx-restart.tmp. Un autre nom conviendrait, sans point ni tilde.

  3. Écrire la ligne, puis quitter. 
    marie ALL = (root) NOPASSWD: /usr/bin/systemctl restart nginx

    À la sortie, visudo n’affiche rien. La question What now? n’apparaît qu’en cas d’erreur, et propose e pour rééditer, x pour abandonner, Q pour enregistrer malgré tout.

  4. Vérifier, puis tester. 
    sudo visudo -c
sudo -l
sudo systemctl restart nginx

    visudo -c affiche une ligne parsed OK par fichier lu. sudo -l liste la règle sous la forme (root) NOPASSWD: /usr/bin/systemctl restart nginx. La dernière commande ne demande aucun mot de passe.

Une règle ignorée produit trois messages différents selon l’origine du problème

Un fichier de /etc/sudoers.d mal formé, mal protégé ou mal nommé ne donne pas le même message, et confondre les trois fait perdre du temps. La page de manuel sudoers(5) liste les messages que sudo écrit quand il refuse un fichier : mauvais propriétaire, fichier inscriptible par tous, mauvais groupe, type non régulier. visudo -c produit de son côté deux avertissements distincts, dont un qui nomme le mode attendu en clair. La différence tient au fait que sudo ne teste pas un mode 0440 exact : la page de manuel écrit que le fichier ne doit pas être inscriptible par tous, et que 0440 est le mode par défaut. Un fichier root:root en 0644 passe donc le contrôle de sudo, alors qu’un fichier en 0664 appartenant à un autre groupe est rejeté.

Le refus le plus fréquent vise un fichier inscriptible par tout le monde :

sudo: /etc/sudoers.d/90-nginx-restart is world writable

Un fichier appartenant à un autre compte que root donne un message voisin :

sudo: /etc/sudoers.d/90-nginx-restart is owned by uid 1000, should be 0

Deux cas se rattachent plus difficilement à leur cause. Le premier vient du nom du fichier, que sudo écarte sans autre explication :

ignoring file name containing '.'

Le second vient de visudo -c, plus strict que sudo sur les permissions du fichier :

/etc/sudoers.d/90-nginx-restart: bad permissions, should be mode 0440

Le remède tient en deux commandes, à passer avec sudo :

sudo chown root:root /etc/sudoers.d/90-nginx-restart
sudo chmod 0440 /etc/sudoers.d/90-nginx-restart

L’ordre lexical décide de l’entrée qui l’emporte, car la page de manuel sudoers(5) note que /etc/sudoers.d/1_whoops est chargé après /etc/sudoers.d/10_second. Le wiki Arch ajoute qu’un fichier mal formé empêche sudo de fonctionner dans son ensemble. Depuis sudo 1.9.3, sudo tente de récupérer en abandonnant la fin de la ligne fautive.

Portée, chemins exigés et utilisateurs visés changent selon la forme de la ligne

Chaque forme de règle NOPASSWD couvre un nombre de commandes différent, et c’est cette portée qui décide du risque réel. Une ligne visant un binaire unique n’ouvre que ce binaire. Un alias Cmnd_Alias nomme explicitement chaque chemin, et sudo refuse alors toute commande absente de la liste. Une entrée visant un répertoire terminé par une barre oblique ouvre tous les fichiers de ce répertoire, mais pas ceux de ses sous-répertoires, précision que la page de manuel sudoers(5) donne dans la section consacrée aux listes de commandes. La forme la plus large, NOPASSWD: ALL, supprime l’authentification pour tout, ce que la documentation du projet sudo signale comme dangereux. Le mode 0440 n’intervient pas dans ce classement, puisque sudo contrôle la propriété et l’absence d’écriture pour tous, pas un mode précis.

Forme écrite dans /etc/sudoers.d Nombre de commandes sans mot de passe Chemins à écrire Comptes visés
NOPASSWD suivi d’un chemin absolu 1 1 le compte nommé en tête de ligne
NOPASSWD suivi d’un Cmnd_Alias de 6 chemins 6 6 le compte nommé en tête de ligne
Ligne commençant par %sudo 1 1 tous les membres du groupe
NOPASSWD suivi d’un répertoire terminé par une barre oblique tous ceux du répertoire, sous-dossiers exclus 1 le compte nommé en tête de ligne
NOPASSWD: ALL toutes celles de la machine aucun le compte nommé en tête de ligne

Les valeurs par défaut qui encadrent une règle NOPASSWD ne sont pas les mêmes partout. Selon la page de manuel sudo(8) de Debian 12 et celle de Debian 13, le cache d’authentification dure 15 minutes, contre 5 minutes dans la page de manuel sudoers(5) du projet sudo en version 1.9.18. Une commande couverte par NOPASSWD échappe entièrement à ce cache.

Source et version de sudo Délai avant nouvelle demande du mot de passe
Manuel sudo(8) de Debian 12, sudo 1.9.13p3-1+deb12u4 15 minutes
Manuel sudo(8) de Debian 13, sudo 1.9.16p2-3+deb13u2 15 minutes
Manuel sudoers(5) du projet sudo, version 1.9.18 5 minutes

Le suivi de paquets Debian donne sudo 1.9.17p2-8 en testing au 13 septembre 2026, la branche stable trixie restant en 1.9.16p2-3+deb13u2. La version minimale utile ici est 1.9.3, première version à tenter une récupération après une erreur de syntaxe.

Le cache d’authentification, le groupe et le terminal décident de l’effet réel

Un cache d’authentification, un groupe et un terminal décident de l’effet réel d’une règle NOPASSWD, avant même la question du chemin. Le cache explique qu’une commande autorisée par mot de passe reste silencieuse pendant un quart d’heure sur Debian, puis réclame de nouveau le mot de passe, alors qu’une commande couverte par NOPASSWD ne le réclame jamais. Ce même groupe décide du nombre de personnes touchées par une seule ligne. Le terminal décide de la possibilité même de s’authentifier : la page de manuel sudo(8) de Debian 12 documente le message a terminal is required to read the password, qui apparaît quand aucun terminal n’est disponible. D’un cas à l’autre, la durée de protection perdue passe de 0 à 15 minutes.

Combien de temps une règle NOPASSWD laisse-t-elle la commande accessible sans mot de passe ?

Sans limite de durée : le tag NOPASSWD supprime l’authentification, il ne la met pas en cache. La protection perdue se compte donc en minutes de cache, soit 15 minutes sur Debian 12 et Debian 13 d’après leur page de manuel sudo(8), et 5 minutes pour sudo 1.9.18.

Une ligne par commande ou un alias Cmnd_Alias : que choisir au-delà de six commandes ?

L’alias devient plus lisible dès la troisième commande, parce qu’il sépare la liste des chemins de la ligne qui accorde le droit. Il impose de nommer chaque chemin en entier et de ne pas réutiliser un nom déjà pris dans /etc/sudoers, ce que la page de manuel sudoers(5) qualifie d’erreur de syntaxe.

Comment couvrir huit personnes sans écrire huit lignes ?

En plaçant un pourcentage devant le nom de groupe, comme dans %sudo ALL = (root) NOPASSWD: /usr/bin/systemctl restart nginx. La commande getent group sudo affiche les membres avant l’écriture, et le fichier ne contient plus qu’une ligne quand quelqu’un entre ou sort du groupe.

Une faute dans /etc/sudoers.d bloque-t-elle sudo pour toute la machine ?

Le wiki Arch répond oui : un fichier mal formé empêche sudo de fonctionner, comme une faute dans /etc/sudoers. Depuis sudo 1.9.3, la page de manuel sudoers(5) précise que le programme tente de récupérer en abandonnant la fin de la ligne fautive. La sortie de secours consiste à démarrer en mode de récupération et à supprimer le fichier fautif.

Le joker /usr/bin/systemctl * ouvre-t-il plus que prévu ?

Oui, et la page de manuel sudoers(5) le documente : les arguments sont comparés comme une seule chaîne, donc un astérisque franchit les limites de mots. Une entrée comme /bin/cat /var/log/messages* autorise aussi bien messages.1 que messages suivi de /etc/shadow. Écrire "" à la place des arguments interdit toute option.

Une règle NOPASSWD fonctionne-t-elle depuis cron ou une unité systemd, sans terminal ?

Oui, et c’est le cas d’usage qui justifie le tag : sans terminal, sudo ne peut pas poser sa question, et la page de manuel sudo(8) de Debian 12 documente l’échec a terminal is required to read the password. L’option requiretty, désactivée par défaut selon la page de manuel sudoers(5), n’a pas à être modifiée.

Sources

Quatre domaines officiels portent les faits techniques de cette page, et chacun couvre un aspect différent du tag NOPASSWD. La page de manuel sudoers(5) du projet sudo fixe la grammaire des entrées, le sens du tag et les messages d’erreur, et c’est elle qui donne 0440 comme mode par défaut du fichier. Les pages de manuel Debian servent de référence pour ce qui est réellement installé : elles donnent sudo 1.9.16p2-3+deb13u2 en trixie et 1.9.13p3-1+deb12u4 en bookworm, ainsi que le délai de 15 minutes du cache d’authentification. Le wiki Arch décrit le comportement du répertoire /etc/sudoers.d. Le suivi de paquets Debian donne les versions par distribution, dont sudo 1.9.17p2-8 en testing au 13 septembre 2026.