Administrer un système Linux implique régulièrement d’accéder à des privilèges éventuellement réservés, une nécessité qui pousse les utilisateurs à manier des commandes comme sudo, su et su –. Ces trois outils permettent d’exécuter des actions avec des droits administrateur, mais ils fonctionnent selon des mécanismes radicalement différents, et cette distinction conditionne directement la sécurité, la traçabilité et l’efficacité de chaque interaction avec le système.
Qu’est-ce qui différencie fondamentalement sudo, su et su – ?
Bien que ces trois commandes convergent vers un objectif similaire — obtenir des droits élevés pour exécuter des tâches administratives — leurs approches divergent sensiblement. La compréhension de ces nuances devient indispensable pour quiconque manipule des systèmes Linux, que ce soit dans un contexte professionnel ou personnel.
sudo fonctionne selon un principe de délégation de droits temporaire. Lorsqu’un utilisateur standard exécute une commande précédée de sudo, il demande au système de lancer cette commande avec les privilèges d’un autre utilisateur, généralement root. Pour ce faire, l’utilisateur s’authentifie avec son propre mot de passe, pas celui du compte cible. Cette commande requiert une autorisation explicite, définie dans le fichier /etc/sudoers, qui détermine précisément quelles commandes chaque utilisateur est autorisé à exécuter avec des droits élevés.
su, dont le nom signifie « Substitute User », adopte une stratégie radicalement différente. Elle bascule complètement vers la session d’un autre utilisateur, généralement root, en demandant le mot de passe de cet utilisateur cible. Une fois l’authentification réussie, l’utilisateur se retrouve dans un shell root, conservant toutefois l’environnement de son compte initial — c’est un point crucial.
su – présente une variante de su qui charge également l’environnement complet de l’utilisateur cible. Cela signifie que toutes les variables d’environnement, les chemins d’accès aux répertoires et les configurations spécifiques à ce compte sont activées, créant une session quasi-identique à celle que l’utilisateur cible obtiendrait en se connectant directement.
Comment fonctionne la commande sudo et quand l’utiliser ?
La commande sudo permet à un utilisateur d’exécuter des tâches avec un niveau de privilège plus élevé sans avoir besoin de partager le mot de passe root. Cela garantit une meilleure traçabilité des actions effectuées sur le système.
La philosophie de sudo repose sur la traçabilité et le contrôle granulaire. Chaque commande exécutée via sudo est enregistrée dans les journaux système, créant un historique complet des actions administratives. Cet enregistrement inclut le timestamp, l’utilisateur qui a lancé la commande et la commande elle-même, facilitant les audits de sécurité et les enquêtes en cas de problème.
Pour utiliser sudo, un utilisateur doit d’abord être autorisé via le fichier /etc/sudoers. Un administrateur système configure ce fichier pour spécifier exactement quelles commandes chaque utilisateur peut exécuter avec des privilèges élevés. Par exemple, un administrateur pourrait autoriser un utilisateur à relancer des services spécifiques sans lui donner un accès root complet.
La syntaxe basique de sudo est simple : sudo nom_commande. Lors de la première utilisation, l’utilisateur doit entrer son propre mot de passe. Par défaut, sudo se souvient de l’authentification pendant une courte période (généralement quinze minutes), évitant à l’utilisateur de saisir son mot de passe à chaque commande successive.
Pratiquement, imaginons qu’un utilisateur appelé « marie » souhaite redémarrer le service web Apache. Elle exécuterait sudo systemctl restart apache2, puis entre son mot de passe. Le système vérifie si marie est autorisée à exécuter cette commande précise dans /etc/sudoers. Si c’est le cas, la commande s’exécute avec les privilèges root.
Avantages et cas d’usage recommandés de sudo
📌 sudo excelle dans les environnements où la sécurité et la traçabilité sont primordiales. Les entreprises l’apprécient car elle permet de déléguer des responsabilités spécifiques sans distribuer le mot de passe root. Un développeur peut ainsi redémarrer un service sans pouvoir supprimer arbitrairement des fichiers système.
C’est la commande idéale pour les administrateurs qui gèrent plusieurs utilisateurs sur une même machine. Chacun reçoit exactement les permissions nécessaires à ses tâches, rien de plus. Ce principe, connu sous le nom de moindre privilège, renforce considérablement la sécurité du système.
De plus, sudo s’intègre harmonieusement dans les politiques d’authentification centralisées. Une organisation peut synchroniser les autorisations sudo avec un serveur LDAP ou Active Directory, garantissant une gestion cohérente des accès à travers tous ses systèmes Linux.
Comprendre su et su – : basculer d’utilisateur et charger l’environnement
Contrairement à sudo, su ne délègue pas des droits temporaires. Elle effectue un véritable changement d’utilisateur. Lorsque vous exécutez su suivi du mot de passe root, le système vous transforme littéralement en utilisateur root, fermant votre session d’origine et ouvrant celle du nouvel utilisateur.
Une distinction cruciale sépare su de su –. Avec su seul, vous basculez vers root mais conservez partiellement votre environnement initial. Les variables d’environnement, le répertoire courant et les configurations de profil de votre compte restent actifs. C’est comme entrer dans un bâtiment avec une clé différente tout en gardant votre manteau et vos affaires personnelles.
su –, en revanche, crée une session de connexion complète pour l’utilisateur cible. Imaginez que vous vous déconnectez complètement, puis que root se connecte normalement à la machine. C’est l’effet produit par su –. Tous les fichiers de configuration de root (comme .bashrc, .profile, .bash_profile) sont chargés, activant les variables d’environnement personnalisées et les alias que root a configurés.
La différence pratique entre su et su – : l’environnement en action
Pour illustrer cette distinction de manière concrète, prenons un exemple concret. Supposez que l’utilisateur « thomas » est actuellement connecté et souhaite basculer vers root. S’il exécute simplement su, il accède à un shell root mais reste dans le répertoire personnel de thomas, typiquement /home/thomas.
En contraste, s’il utilise su –, il se retrouve immédiatement dans le répertoire root /root, car le profil de root a défini le chemin home approprié. Cette différence peut sembler anodine, mais elle impacte la façon dont les scripts et les applications localisent leurs fichiers de configuration.
Imaginons maintenant que root a défini une variable d’environnement personnalisée dans son fichier .profile :
export APP_CONFIG= »/etc/app/config »
Si thomas utilise su puis essaie d’accéder à cette variable avec echo $APP_CONFIG, le système retournera vide, car cette variable n’existe que dans l’environnement complet de root. Si thomas utilise su – puis exécute la même commande, le système affichera correctement /etc/app/config.
🔑 Cette nuance devient critique lorsque vous exécutez des scripts qui dépendent de variables d’environnement spécifiques ou de chemins relatifs. Un script système écrit pour root peut mal fonctionner si l’environnement n’est pas complètement chargé.
Quand choisir su ou su – ?
su est appropriée lorsque vous devez exécuter quelques commandes rapides avec des droits root sans bouleverser votre environnement de travail. Un administrateur qui doit rapidement vérifier un fichier système peut préférer rester dans son répertoire de travail initial.
su – s’impose quand vous lancez des tâches système complexes, des installations logicielles ou des scripts qui dépendent de l’environnement de root. Elle garantit que tous les profils et variables sont disponibles, éliminant les surprises liées aux chemins ou configurations manquantes.
📊 Dans la pratique moderne, beaucoup d’administrateurs recommandent même d’éviter complètement su au profit de su – pour ces raisons d’intégrité environnementale. Cela prévient les erreurs subtiles causées par des configurations partielles.
Pourquoi sudo su est déconseillée et quelles alternatives privilégier ?
Il arrive que des utilisateurs tapent sudo su, combinant les deux approches. Techniquement, cela fonctionne : sudo exécute su avec les privilèges root, ouvrant un shell root. Cependant, cette pratique présente des failles de sécurité significatives que les administrateurs systèmes considèrent comme des signaux d’alerte.
Le problème principal concerne la traçabilité. Lorsque vous utilisez sudo su, seule l’exécution de su est enregistrée dans les journaux sudo. Les commandes que vous exécutez ensuite dans le shell root ne sont pas tracées par sudo, car vous n’utilisez plus sudo — vous utilisez un shell root brut. Cette lacune dans l’audit peut causer des problèmes légaux et de sécurité dans les environnements régulés.
Un second problème concerne la circumvention des restrictions. Supposez qu’un administrateur a configuré /etc/sudoers pour autoriser « julie » à exécuter uniquement la commande systemctl restart nginx via sudo. Si julie connaît le mot de passe root, elle peut exécuter sudo su, ouvrir un shell root complet et contourner entièrement ces restrictions, exécutant n’importe quelle commande. Cela anéantit la sécurité granulaire que sudo était censée fournir.
Alternatives sécurisées : sudo -i et sudo -s
📋 Pour reproduire le comportement de su et su – tout en préservant la traçabilité de sudo, utilisez plutôt :
- 💻 sudo -i : équivalent de su –, lance un shell root avec l’environnement complet de root. Chaque commande exécutée reste tracée via sudo.
- 💻 sudo -s : équivalent de su, lance un shell root conservant partiellement votre environnement initial. La traçabilité sudo est maintenue.
- 💻 sudo -u username : bascule vers un utilisateur spécifique, utile pour des tâches ne nécessitant pas les droits root.
- 💻 sudo -l : liste les commandes que vous êtes autorisé à exécuter, idéal pour vérifier vos permissions sans action.
Ces alternatives combinent la puissance de su avec la traçabilité et le contrôle de sudo. Un administrateur qui configure sudo -i pour un utilisateur sait précisément quand et par qui root a été sollicité, sans risque de contournement.
🛡️ La meilleure pratique consiste à interdire complètement le mot de passe root (une pratique appelée « disabling root login ») et de forcer tous les accès administratifs via sudo. Cela centralise la gouvernance et élimine les tentations d’utiliser su.
Tableau comparatif : sudo, su et su – face à face
Pour synthétiser les différences majeures, voici une comparaison structurée des trois commandes selon leurs caractéristiques principales :
| 🔑 Aspect | sudo | su | su – |
|---|---|---|---|
| Authentification | Votre propre mot de passe | Mot de passe du compte cible (root) | Mot de passe du compte cible (root) |
| Basculement d’utilisateur | Non, délégation temporaire | Oui, changement complet | Oui, changement complet |
| Environnement chargé | Environnement de l’utilisateur initial | Partiellement conservé | Entièrement chargé (root) |
| Traçabilité | ✅ Complète dans les journaux sudo | ❌ Non tracée par sudo | ❌ Non tracée par sudo |
| Autorisation requise | ✅ Via /etc/sudoers | ❌ Juste le mot de passe | ❌ Juste le mot de passe |
| Contrôle granulaire | ✅ Commandes spécifiques | ❌ Tout ou rien | ❌ Tout ou rien |
| Cas d’usage idéal | 📌 Tâches isolées, environnements d’entreprise | 📌 Actions rapides en environnement de confiance | 📌 Sessions interactives complètes |
Cette comparaison révèle que sudo brille dans les contextes exigeant sécurité et traçabilité, tandis que su et su – conviennent mieux aux environnements locaux où l’utilisateur possède déjà le mot de passe root. Les distributions Linux modernes, particulièrement dans les contextes serveurs, tendent à favoriser sudo précisément pour ces avantages de gouvernance.
Utilisez la commande visudo pour éditer de manière sécurisée le fichier /etc/sudoers : elle valide la syntaxe avant de sauvegarder, évitant ainsi les erreurs potentielles.
Configurer et sécuriser l’accès aux privilèges root
Mettre en place une politique d’accès aux privilèges root nécessite une planification réfléchie. La plupart des distributions Linux modernes, comme Ubuntu, Debian et les variantes Red Hat, recommandent une approche basée sur sudo plutôt que sur un accès direct à root.
Le point central de cette configuration est le fichier /etc/sudoers. Ce fichier définit qui peut exécuter quoi avec quels privilèges. Un administrateur système doit l’éditer uniquement via la commande visudo, qui valide la syntaxe avant sauvegarde. Une erreur dans sudoers peut rendre sudo inutilisable, d’où l’importance de cette validation.
Une entrée typique dans sudoers ressemble à :
marie ALL=(ALL) /usr/bin/systemctl
Cette ligne autorise marie à exécuter systemctl sur n’importe quelle machine (ALL) en tant que n’importe quel utilisateur (=(ALL)). Pour plus de sécurité, on pourrait restreindre davantage :
marie ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart apache2
Ici, marie peut relancer Apache sans entrer son mot de passe. Cette flexibilité permet d’automatiser certaines tâches tout en gardant un contrôle strict.
Bonnes pratiques de sécurité pour la gestion des permissions
🛡️ Désactiver l’accès root direct : interdisez les connexions SSH en tant que root et forcez l’utilisation de sudo. Cela crée une barrière supplémentaire contre les accès non autorisés.
🛡️ Implémenter le principe du moindre privilège : n’accordez que les permissions strictement nécessaires. Un développeur n’a pas besoin d’accéder à tous les fichiers système, seulement à ceux pertinents pour ses tâches.
🛡️ Utiliser des groupes sudo : au lieu de configurer chaque utilisateur individuellement, créez des groupes (comme « web-admins » ou « db-admins ») et assignez les permissions au groupe. Cela simplifie la gestion et réduit les erreurs.
🛡️ Auditer régulièrement les journaux : consultez régulièrement /var/log/auth.log ou /var/log/secure pour identifier les accès anormaux ou les tentatives échouées.
🛡️ Configurer un timeout sudo approprié : par défaut, sudo mémorise l’authentification pendant 15 minutes. Pour des environnements sensibles, réduisez ce délai.
La combinaison de ces pratiques crée un environnement Linux à la fois fonctionnel et sécurisé. Les organisations qui appliquent ces principes réduisent drastiquement le risque de compromission accidentelle ou malveillante.
Saisir les différences entre sudo, su et su – transforme profondément la façon dont un administrateur ou un utilisateur Linux interagit avec son système. sudo incarne la rigueur sécuritaire moderne, su offre une transition rapide pour les tâches ponctuelles, tandis que su – assure l’intégrité environnementale pour les sessions complètes. Rejeter sudo su au profit des alternatives recommandées renforce à la fois la traçabilité et la gouvernance. Ces choix, apparemment techniques, reflètent une philosophie plus large de responsabilité et de contrôle dans l’administration système, particulièrement dans les environnements critiques où chaque action compte.
