`useradd` vs. `adduser` : analyse comportementale et implications pour la portabilité des scripts de déploiement

Dans l’écosystème Linux, la gestion des comptes utilisateurs est régie par un ensemble de primitives définies par les spécifications POSIX et les standards LSB (Linux Standard Base). Parmi ces primitives, la création de compte est l’une des plus fréquemment automatisées dans les workflows DevOps, les playbooks Ansible et les scripts de bootstrapping d’infrastructure.

Or, deux commandes coexistent pour accomplir cette tâche : useradd, définie dans la suite shadow-utils, et adduser, introduite par les distributions Debian et Ubuntu comme interface conviviale. Leur proximité syntaxique induit systématiquement des confusions, aux conséquences parfois graves : comptes créés sans répertoire personnel, UID hors des plages conventionnelles, groupes supplémentaires absents.

« La ressemblance nominale entre useradd et adduser constitue un piège classique : deux outils, deux philosophies, deux niveaux d’abstraction. »

Cet article propose une analyse rigoureuse de leurs différences comportementales, en s’appuyant sur les sources primaires (code source, pages de manuel, fichiers de configuration) et sur des observations empiriques réalisées sur Debian 12, Ubuntu 22.04, Alpine 3.19 et CentOS Stream 9.

2. Modèles d’exécution

2.1 useradd — la primitive

useradd est distribué dans le paquet shadow-utils et opère directement sur les fichiers de la base de comptes système (/etc/passwd, /etc/shadow, /etc/group). Son comportement est non-interactif, déterministe, et strictement limité aux paramètres passés en ligne de commande.

En l’absence de l’option -m, aucun répertoire personnel n’est créé ; le squelette /etc/skel n’est pas copié. En l’absence de -U, aucun groupe privé n’est instancié. Cette sémantique de moindre surprise en fait l’outil de prédilection pour les scripts, mais une source de pièges pour l’administrateur pressé.

Flux d’exécution :

Appel useradd → Parse les options CLI → Écrit /etc/passwd + /etc/shadow
              → [si -m] Crée le home et copie /etc/skel
              → Sortie silencieuse (exit 0)

Fig. 1 — La création du répertoire personnel est conditionnelle à la présence explicite de -m.

2.2 adduser — l’abstraction Debian

Sur les systèmes Debian et Ubuntu, adduser est un script Perl qui s’appuie sur useradd en coulisses. Il applique les conventions de la distribution en lisant /etc/adduser.conf : plages d’UID/GID, répertoire de base, shell par défaut, liste des groupes supplémentaires. Le répertoire personnel est systématiquement créé et le squelette /etc/skel intégralement copié. Le mot de passe est demandé interactivement.

⚠️ Ambiguïté critique. Sur Alpine Linux, une commande adduser existe également — mais il s’agit de la version BusyBox, dont la syntaxe et le comportement diffèrent radicalement de l’implémentation Debian. L’identité nominale des deux commandes constitue une source d’erreur non détectée à l’exécution.

3. Analyse comparative des comportements

Le tableau suivant synthétise les différences observées lors du protocole de test, exécuté sans options supplémentaires sauf indication contraire.

Tab. 1 — Comparaison comportementale entre useradd et adduser sur Debian 12 / Ubuntu 22.04.

4. Implications pour la portabilité

Le choix inadapté de l’outil se manifeste selon deux scenarii récurrents.

Le premier concerne les scripts d’automatisation écrits sur un poste Debian, utilisant adduser, déployés ensuite sur une cible Alpine ou CentOS : la commande échoue ou produit un comportement divergent. Le second concerne l’utilisation de useradd sans l’option -m lors d’un provisionnement manuel, aboutissant à un compte valide mais dépourvu de home — condition suffisante pour provoquer des erreurs d’authentification SSH basée sur clé.

📌 Note méthodologique. La règle de portabilité est simple : tout script destiné à être exécuté sur plus d’une distribution doit utiliser exclusivement useradd, en spécifiant explicitement chaque comportement attendu via les flags appropriés.

5. Reproduction du comportement d’adduser avec useradd

L’exemple ci-dessous montre comment encapsuler useradd pour obtenir un comportement analogue à adduser, tout en conservant la portabilité inter-distributions. La fonction vérifie l’existence du compte, délègue la création à useradd -m -U, puis applique le mot de passe via chpasswd.

⚠️ Avertissement de sécurité. Passer un mot de passe en argument de ligne de commande le rend visible dans l’historique shell et dans la sortie de ps. En production, préférer chpasswd -e avec un hash pré-calculé, ou laisser passwd opérer interactivement.

#!/bin/bash

add_user() {
  local username=$1 realname=$2 password=$3
  local homedir=$4  shell=$5    groups=$6

  # Vérification de l'existence préalable du compte
  if id -u "$username" >/dev/null 2>&1; then
    echo "[ERREUR] L'utilisateur $username existe déjà." >&2
    return 1
  fi

  # -m : crée le home et copie /etc/skel
  # -U : crée un groupe privé homonyme
  useradd -c "$realname" \
          -d "$homedir"  \
          -s "$shell"    \
          -G "$groups"   \
          -m -U "$username" || return 1

  # Application du mot de passe par chpasswd (évite l'exposition dans ps)
  [ -n "$password" ] && printf '%s:%s\n' "$username" "$password" | chpasswd

  return 0
}

# Exemple d'appel
add_user "jdoe" "John Doe" "s3cr3t" "/home/jdoe" "/bin/bash" "sudo,www-data"

6. Recommandations

7. Conclusion

La distinction entre useradd et adduser illustre un pattern architectural récurrent dans l’écosystème Linux : la coexistence entre une primitive bas niveau, portable mais bavarde en options, et une abstraction de haut niveau, confortable mais à périmètre de distribution limité. Confondre les deux, ou supposer que le comportement de l’une est implicitement reproduit par l’autre, est une source d’incidents documentée dans les bases de tickets de nombreuses équipes opérationnelles.

La règle est simple à formuler : useradd pour les machines, adduser pour les humains travaillant sous Debian. Sa mémorisation évite un home manquant à 3h du matin.

Références

[1] shadow-utils source code, Tomáš Mráz et al., GitHub (shadow-maint/shadow), consulté juin 2026.
[2] Debian Policy Manual, §10.9 — Users and groups, Debian Project, 2024.
[3] adduser(8) — Debian manpage, Marc Haber & Joerg Hoh, 2023.
[4] BusyBox Reference Manual — applet adduser, Denys Vlasenko, 2024.
[5] Linux Standard Base Core Specification 5.0, §16.2 — User and Group Account Management, The Linux Foundation, 2015.