Linux / Commande su : changer d’utilisateur et de shell de connexion

su est un outil utilisé pour exécuter un shell ou des commandes avec un identifiant utilisateur et un identifiant de groupe alternatifs. Si aucun utilisateur n'est spécifié, il cible généralement root, et l'utilisation de su --login user permet de passer à un environnement similaire à celui d'une connexion directe en tant que cet utilisateur.

Un simple su user conserve le répertoire de travail actuel et une partie de l'environnement, ce qui peut se mélanger avec les paramètres d'un autre utilisateur. Pour un changement de compte interactif, su --login user est généralement utilisé, et si le but est simplement d'exécuter une seule commande administrative, il vaut mieux d'abord considérer si sudo basé sur la politique est plus approprié.

Qu'est-ce que la commande su ?

su exécute un shell ou une commande avec d’autres identifiants d’utilisateur et de groupe. Sans nom d’utilisateur, la commande tente d’ouvrir un shell interactif pour root, le compte superutilisateur.

Le su d’util-linux effectue l'authentification ainsi que la gestion des comptes et des sessions via PAM (Pluggable Authentication Modules). Le mot de passe requis, le fait que seuls certains groupes puissent utiliser su et l'endroit où les tentatives sont enregistrées peuvent varier en fonction des paramètres PAM et de sécurité de la distribution.

Cet article est basé sur l’implémentation d’util-linux, qui est largement utilisée sous Linux. Le comportement exact et les fichiers de configuration spécifiques au système peuvent être trouvés sur la page de manuel officielle d’util-linux su.

Syntaxe de base et changement de compte

La syntaxe de base est la suivante.

su [options] [-] [user [arguments...]]

Si aucun utilisateur n'est spécifié, il tente de passer au compte root.

su

Lancé par un utilisateur ordinaire, su demande généralement le mot de passe du compte cible, ici root. Le mot de passe du compte courant ne le remplace pas. Un compte verrouillé ou une règle PAM restrictive peut empêcher le changement même si le mot de passe du compte cible est connu.

Pour utiliser un compte particulier, indiquez son nom. Dans les exemples, remplacez deploy par un compte existant que vous êtes autorisé à utiliser ; consultez son entrée avec getent passwd deploy avant d’interpréter le shell, le répertoire personnel et les groupes obtenus.

su deploy

Pour revenir au shell d'origine, exécutez exit dans le shell changé ou appuyez sur Ctrl+D.

exit

La différence entre su et su --login

Le manuel util-linux recommande d'utiliser --login pour éviter les effets secondaires des environnements mixtes. La forme courte - a la même signification.

su --login deploy
su - deploy

Modifications dans l'environnement du shell de connexion

Nettoie la plupart des variables d'environnement existantes

Dans les versions récentes d’util-linux, su --login efface l’environnement existant à l’exception de TERM, COLORTERM, NO_COLOR et des variables explicitement autorisées. Il initialise ensuite HOME, SHELL, USER, LOGNAME et PATH pour le compte cible. Vérifiez la version installée lorsque vous dépendez d’une variable conservée précise.

L'environnement final peut également refléter les valeurs ajoutées ou modifiées par les modules PAM, il ne faut donc pas supposer qu'il soit exactement le même selon les distributions. Les fichiers de démarrage du shell peuvent encore modifier ces valeurs.

Se déplacer vers le répertoire personnel de l'utilisateur cible

--login démarre le shell de connexion après s'être déplacé vers le répertoire personnel de l'utilisateur cible. Après le changement, vous pouvez vérifier l'utilisateur, le répertoire personnel et le répertoire de travail avec les commandes suivantes.

id
printf '%s\n' "$HOME"
pwd

Les fichiers d'initialisation du shell changent

Le shell de connexion lit les fichiers d'initialisation pour la connexion selon les règles du shell utilisé. Pour Bash, cela peut être influencé par les paramètres système et utilisateur tels que /etc/profile et ~/.bash_profile. Consultez le manuel du shell cible et les paramètres du compte pour l'ordre réel.

Options su fréquemment utilisées

Exécuter une seule commande sous l’identité d’un autre utilisateur

Exécuter une commande avec -c

Si vous n'avez pas besoin de rester dans un shell interactif, vous pouvez passer des commandes au shell de l'utilisateur cible avec -c.

su -c 'id' deploy

Lorsque la commande se termine, su se termine également et retourne au shell original. Comme la chaîne de commande est réinterprétée par le shell cible, faites attention aux guillemets, à l'expansion des variables et au moment de la redirection.

Exécuter des commandes dans un environnement de connexion

Pour exécuter des commandes dans l'environnement de connexion et le répertoire personnel de l'utilisateur cible, utilisez --login ensemble.

su --login -c 'pwd; id' deploy

Les deux commandes reliées par un point-virgule sont exécutées à l'intérieur du shell de l'utilisateur cible. Ne passez pas directement des chaînes créées dynamiquement avec des privilèges élevés si elles incluent des entrées externes, car cela risque une injection de commandes.

Vérification du statut de sortie des commandes

su renvoie généralement le statut de sortie de la commande exécutée. Dans l'implémentation util-linux, il renvoie 126 si la commande ne peut pas être exécutée, 127 si la commande est introuvable et 1 pour des erreurs générales avant l'exécution de la commande.

su -c 'exit 7' deploy
status=$?
printf 'exit=%s\n' "$status"

Si l’authentification et le lancement du shell aboutissent, l’exemple précédent affiche exit=7 : ce code a été choisi volontairement dans la commande exécutée. Un échec préalable de su peut produire un autre code. Vérifiez donc le statut et le message d’erreur, pas seulement la sortie affichée.

Gestion des shells et des comptes restreints

Shell par défaut de l'utilisateur cible

Sauf indication contraire, le shell défini dans l'entrée passwd du compte cible est généralement utilisé, et s'il est absent, il prend par défaut /bin/sh. Lors de la vérification des informations du compte, ne modifiez pas arbitrairement l'ensemble de /etc/passwd ; interrogez-le plutôt comme suit.

getent passwd deploy

Spécifier le shell avec -s

Vous pouvez spécifier un shell différent avec -s.

su -s /bin/sh -c 'id' deploy

Si le shell du compte cible est un shell restreint non répertorié dans /etc/shells, le shell spécifié par un utilisateur classique peut être ignoré. Le fait que root puisse contourner la restriction ne signifie pas qu'il soit sûr d'ouvrir un shell interactif pour un compte de service.

Respecter l'objectif des comptes de service

Les comptes avec nologin ou false définis comme shell ne sont probablement pas destinés aux connexions interactives. Si vous devez travailler avec un tel compte, exécutez seulement la commande nécessaire et vérifiez d'abord s'il existe des commandes de gestion fournies par le service ou si les fonctionnalités systemd sont disponibles.

Utilisez la préservation des variables d'environnement avec précaution

Signification de --preserve-environment

L'option --preserve-environment préserve l'environnement actuel sans réinitialiser HOME, SHELL, USER ou LOGNAME. Elle est ignorée si spécifiée avec --login.

su --preserve-environment deploy

Sauf dans le cas spécial où les paramètres de l'utilisateur appelant doivent être transmis tels quels, le mélange de l'environnement d'accueil et d'exécution du compte cible peut entraîner des modifications inattendues de la propriété des fichiers ou de la configuration.

Autoriser uniquement les variables nécessaires

Dans util-linux, vous pouvez préserver uniquement les variables nécessaires en combinant --login et --whitelist-environment.

su --login --whitelist-environment=LANG,LC_ALL deploy

HOME, SHELL, USER, LOGNAME, et PATH sont exclus de la liste blanche. Les variables de locale peuvent également affecter le comportement du programme, alors ne transmettez que les valeurs absolument nécessaires.

Différence entre su et sudo

La méthode d'authentification et la journalisation peuvent varier selon le PAM et la politique, donc le tableau ci-dessus est une comparaison générale. Si seule une commande root est nécessaire, sudo, qui peut limiter les privilèges par commande, est souvent plus approprié que su, qui partage le mot de passe du compte. Pour une utilisation détaillée, se référer à la commande sudo Linux et la configuration des sudoers.

Raison de ne pas passer au compte root

Le compte root peut être verrouillé

Certaines distributions désactivent la connexion par mot de passe pour le compte root par défaut et utilisent l'administration via sudo. Dans ce cas, entrer le mot de passe de l'utilisateur actuel dans su - ne réussira pas.

Si l'utilisateur dispose des privilèges sudo et que la politique le permet, un shell root de type connexion peut être ouvert comme suit, mais si seules des commandes individuelles sont nécessaires, il est plus sûr d'utiliser sudo command plutôt qu'un shell administrateur.

sudo -i

PAM ou les politiques de groupe peuvent imposer des restrictions

La politique dans /etc/pam.d/su peut restreindre l'utilisation de su à des groupes spécifiques ou imposer des exigences d'authentification supplémentaires. Ne modifiez pas arbitrairement les paramètres PAM pour obtenir des privilèges ; fournissez plutôt à l'administrateur système les tâches nécessaires et les comptes cibles.

Il peut y avoir des problèmes avec l'état du compte cible

Le changement peut échouer en raison de l'expiration du compte, du verrouillage, du répertoire personnel incorrect, du shell restreint ou des permissions de fichiers. Si vous êtes administrateur, vérifiez la cause avec getent passwd user, les outils de gestion de comptes et les journaux d'authentification.

Lorsque root s'exécute sous l’identité d’un autre utilisateur

runuser peut être plus adapté pour l'automatisation

Pour une tâche déjà lancée par root, le manuel util-linux recommande runuser. Cet outil n’a pas besoin du bit set-user-ID, ne demande pas de mot de passe et utilise une configuration PAM distincte. Dans l’exemple suivant, root lance seulement id avec l’identité du compte backup ; remplacez ce nom par un compte existant adapté à votre tâche.

runuser -u backup -- id

Vérifiez que la sortie de id correspond au compte cible et à ses groupes. runuser est réservé à root : il ne donne pas à un utilisateur ordinaire un moyen de contourner la politique sudo.

Si une session PAM n'est pas nécessaire, reconsidérez l'objectif

Si vous avez simplement besoin de changer les identifiants utilisateur/groupe et les attributs de permission pour exécuter un programme et qu'une session PAM n'est pas nécessaire, util-linux suggère également setpriv comme alternative. Cet outil gère directement les privilèges et les attributs de sécurité, il ne doit donc être utilisé que par des administrateurs qui comprennent exactement les paramètres d'utilisateur, de groupe, de groupe supplémentaire et de capacité.

Séparer la session avec un pseudo-terminal

Séparation fournie par --pty

--pty crée un pseudo-terminal séparé entre la session originale et la session cible, et su relaie l'entrée et la sortie. Cela peut améliorer la sécurité en empêchant les deux sessions de partager directement le même terminal dans une session interactive.

su --pty --login deploy

Pas une session complète de connexion systemd

Même en utilisant su --login, cela ne crée pas une session de connexion entièrement nouvelle du point de vue de systemd-logind. Si vous avez besoin de tâches nécessitant des services utilisateur, des postes de travail (seats) ou une véritable frontière de session, vous devriez envisager des outils adaptés à cet usage, tels que systemd-run ou machinectl.

Précautions de sécurité

• Ne partagez pas le mot de passe root ou les mots de passe d'autres utilisateurs avec plusieurs personnes.
• Ne mettez pas de mots de passe dans la ligne de commande, l'historique du shell, les scripts ou les pipes.
• Ne gardez pas un shell root ouvert plus longtemps que nécessaire ; utilisez exit immédiatement après avoir terminé votre travail.
• Immédiatement après le changement, vérifiez id, pwd et HOME pour éviter toute confusion entre les utilisateurs et les chemins.
• Pour que les commandes soient exécutées avec des privilèges élevés, examinez d'abord les options, les chemins cibles et les résultats des expansions de caractères génériques.
• Ne supposez pas que les journaux sont conservés ; vérifiez plutôt les paramètres réels et les politiques de conservation des journaux PAM, journal et d'authentification.

Les commandes exécutées après l'ouverture d'un shell root avec su sont séparées des enregistrements d'authentification de su lui-même. Si l'audit des commandes individuelles est requis, vous devez le concevoir en parallèle avec l'audit du shell, la journalisation centralisée ou des méthodes comme sudo qui fournissent des politiques par commande.

Problèmes courants et solutions

Questions fréquemment posées

Quel mot de passe entrez-vous pour su ?

Généralement, vous saisissez le mot de passe de l'utilisateur cible vers lequel vous souhaitez passer. Cependant, si root l'exécute ou si les politiques PAM utilisent différentes méthodes d'authentification, le comportement peut varier. Il est normal que les caractères ne s'affichent pas à l'écran lors de la saisie du mot de passe.

Quelle est la différence entre su et su - ?

su lance un shell root tout en conservant le répertoire actuel et une partie de l'environnement. su - se déplace vers le répertoire personnel de root et configure l'environnement de connexion. Dans util-linux, la forme login est recommandée pour réduire le mélange des environnements.

Comment vérifier l'utilisateur actuel après être passé avec su ?

id est utile pour vérifier à la fois les utilisateurs et groupes réels et effectifs. Si vous avez seulement besoin d’un nom d’utilisateur simple, vous pouvez utiliser whoami, mais pour vérifier les groupes supplémentaires, id fournit plus d’informations.

Est-il acceptable de mettre le mot de passe su dans le script ?

Non. Un mot de passe intégré peut apparaître dans les fichiers, les informations de processus ou les journaux. Pour une tâche déjà exécutée par root, définissez un compte cible et une commande précise avec runuser. Pour une tâche lancée par un utilisateur ordinaire, prévoyez une règle sudoers limitée ou un service dédié, sans incorporer le mot de passe.

Résumé

Pour un changement de compte interactif général, vous pouvez utiliser su --login user, et pour une seule commande, su -c 'command' user. Un simple su user peut mélanger les environnements, il est donc conseillé de vérifier id, HOME et pwd après le changement.

Si l'objectif est d'exécuter juste une seule commande root, sudo, qui fournit un contrôle d'autorisation par commande et un audit, peut être plus approprié. Lors de l'exécution en tant qu'utilisateur différent dans l'automatisation root, considérez runuser.