Whoami sous Linux : vérifier l’utilisateur effectif

Vous lancez une commande après un sudo, un su, depuis une tâche cron ou dans un script de déploiement. Avant de modifier des permissions, de créer un fichier ou de démarrer un service, vérifiez l’identité réellement utilisée par le processus. Le nom affiché dans votre invite de commande ou la variable $USER ne suffit pas.

whoami répond immédiatement avec le nom de l’utilisateur effectif. id va plus loin en affichant l’UID, le groupe principal et les groupes supplémentaires. Les deux commandes permettent de confirmer le contexte d’exécution avant une action sensible.

Commencer par whoami et id

Dans le terminal ou au point exact où le script pose problème, lancez :

whoami
id -un
id -u
id

whoami et id -un affichent le nom de l’utilisateur effectif. id -u renvoie son UID numérique. La dernière commande ajoute le GID principal et les groupes supplémentaires. Sur un compte nommé admin, vous pouvez par exemple obtenir :

admin
admin
1001
uid=1001(admin) gid=1001(admin) groupes=1001(admin),27(sudo)

Le nom est pratique à lire, mais l’UID reste la valeur utilisée par le noyau pour les contrôles de droits. Si un annuaire, un conteneur ou un montage présente des identités inhabituelles, comparez toujours le nom et le numéro. Les pages de manuel de whoami(1) et id(1) confirment que whoami affiche le nom associé à l’UID effectif.

Pourquoi $USER peut vous tromper

$USER est une variable d’environnement. Elle peut venir de la session de connexion, être absente dans cron ou être remplacée avant le lancement d’une commande. Contrôlez-la, mais ne l’utilisez pas comme preuve d’identité :

printf 'USER=%s LOGNAME=%s\n' "${USER:-non-definie}" "${LOGNAME:-non-definie}"
whoami
id -un

env USER=faux-compte whoami

La dernière commande modifie seulement la variable transmise au processus. whoami continue d’interroger l’identité effective et n’affiche pas faux-compte. C’est précisément la différence à retenir pour un script exécuté par cron, systemd, un outil CI/CD ou un service web.

Si vous devez retrouver les comptes réellement connus du système, utilisez plutôt getent passwd. Le guide pour lister les utilisateurs Linux explique aussi la différence entre comptes humains, comptes système et identités fournies par LDAP ou SSSD.

Distinguer l’utilisateur réel de l’utilisateur effectif

Un processus possède notamment un UID réel et un UID effectif. L’UID réel indique l’identité à l’origine du processus. L’UID effectif sert aux contrôles d’accès. Dans une session classique, les deux valeurs sont généralement identiques. Elles peuvent différer avec un programme SUID ou certains changements de privilèges.

printf 'UID effectif : '
id -u
printf 'UID reel : '
id -ru
printf 'Nom effectif : '
id -un
printf 'Nom reel : '
id -run

L’option -r demande à id l’identité réelle au lieu de l’identité effective. -n affiche le nom correspondant au numéro. Si les deux UID diffèrent, arrêtez-vous avant un chown, un chmod ou une écriture dans un dossier système. Identifiez d’abord le binaire lancé et la raison de ce changement de privilèges.

command -v mon-programme
ls -l "$(command -v mon-programme)"
stat "$(command -v mon-programme)"

Contrôler le résultat après sudo ou su

La vérification la plus parlante consiste à exécuter les commandes dans le contexte cible. Avec sudo, remplacez <compte> par le compte de service concerné :

sudo whoami
sudo id

sudo -u <compte> whoami
sudo -u <compte> id
sudo -u <compte> sh -c 'whoami; id; printf "USER=%s\n" "${USER:-absente}"'

sudo whoami affiche normalement root. Avec sudo -u <compte>, le nom et l’UID doivent correspondre à la cible. Pour une automatisation, ajoutez -n afin d’interdire toute demande de mot de passe interactive :

sudo -n -u <compte> id

Si l’autorisation n’existe pas, la commande échoue au lieu de rester en attente. Ne corrigez pas ce refus avec une règle NOPASSWD trop large. Le guide Visudo sous Linux montre comment limiter une règle sudoers à l’utilisateur, la commande et les arguments nécessaires.

Avec su, ouvrez une session de connexion pour charger l’environnement du compte cible, puis contrôlez immédiatement l’identité :

su - <compte> -c 'whoami; id; printf "HOME=%s\n" "$HOME"'

La page de manuel de su(1) détaille la différence entre une session simple et une session de connexion. Celle de sudo(8) couvre l’exécution sous une autre identité et le traitement de l’environnement.

Vérifier les groupes avant de modifier des permissions

Le bon utilisateur peut encore recevoir un refus si le groupe attendu manque ou si la session n’a pas chargé une adhésion récente. Relevez les groupes dans le contexte réel :

id
id -Gn
id -G

sudo -u <compte> id
namei -l /srv/mon-application

id -Gn affiche les noms des groupes, id -G leurs GID. namei -l déroule chaque dossier du chemin et permet de repérer le niveau qui bloque la traversée. Ne lancez pas un chmod -R pour contourner le problème : vous risqueriez d’ouvrir toute l’arborescence alors qu’un groupe absent ou un seul dossier mal réglé explique l’erreur.

Si l’adhésion à un groupe vient d’être modifiée, ouvrez une nouvelle session et vérifiez à nouveau id. Un processus déjà lancé conserve ses groupes tant qu’il n’est pas redémarré.

Bloquer un script lancé sous le mauvais compte

Pour un script de sauvegarde, de déploiement ou de maintenance, ne vous contentez pas d’afficher l’identité. Refusez l’exécution si l’UID ne correspond pas au compte attendu :

#!/usr/bin/env bash
set -euo pipefail

expected_user=backup
expected_uid=$(id -u "$expected_user")
current_uid=$(id -u)

if [[ "$current_uid" != "$expected_uid" ]]; then
  printf 'Erreur : script lance avec uid=%s, uid attendu=%s (%s)\n' \
    "$current_uid" "$expected_uid" "$expected_user" >&2
  exit 1
fi

printf 'Identite valide : %s, uid=%s, groupes=%s\n' \
  "$(id -un)" "$current_uid" "$(id -Gn)"

Testez ce contrôle manuellement avec le compte prévu, puis depuis la tâche cron ou l’unité systemd qui lancera réellement le script. Vérifiez aussi le propriétaire des fichiers créés. Cette dernière étape confirme que le processus travaille bien sous l’identité attendue, avec les groupes chargés dans son contexte d’exécution.