Le chroot, on en parle souvent comme d’une cage pour utilisateur. L’image n’est pas mauvaise, à condition de ne pas la prendre au pied de la lettre. Sur CentOS ou sur une autre distribution Linux, faire un chroot pour un compte revient à lui montrer un faux point de départ dans l’arborescence du système. Au lieu de voir le vrai /, l’utilisateur voit un répertoire choisi par l’administrateur, et pour lui, ce dossier devient sa racine.
Dit comme ça, ça paraît très propre. En pratique, c’est utile, parfois très utile, mais ce n’est pas une baguette magique. Si vous gérez un serveur avec des accès SFTP, des comptes techniques ou un hébergement mutualisé un peu artisanal, comprendre ce mécanisme évite beaucoup d’erreurs. Si vous cherchez d’autres repères autour de l’administration Linux côté hébergement, vous pouvez aussi jeter un oeil à cet article, qui complète bien la logique de cloisonnement des services. Dans le même esprit, cette autre ressource aide à replacer le chroot dans des usages serveur plus concrets.
Contenu
Ce que voit réellement un utilisateur chrooté
# exemple fréquent avec SFTP
Match Group sftpusers
ChrootDirectory /srv/sftp/%u
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
Le plus simple est d’imaginer un couloir d’hôtel dont on a fermé toutes les autres portes. L’utilisateur peut circuler dans sa zone, créer des fichiers, lire ce qu’on lui a autorisé, mais il ne remonte pas librement dans tout le bâtiment. Son environnement peut contenir un dossier home, un sous-répertoire de dépôt, parfois quelques bibliothèques si on veut lui laisser un shell ou certains outils.
Le point important, c’est que le chroot ne change pas l’identité du compte. Il ne transforme pas un utilisateur ordinaire en prisonnier parfait. Il change sa vue du système de fichiers. C’est pour ça qu’on l’emploie souvent pour limiter les dégâts ou pour éviter qu’un compte destiné à une tâche précise se balade partout sur le serveur.
Sur CentOS, l’idée apparaît vite dès qu’on met en place des accès de transfert. Beaucoup d’administrateurs veulent qu’un client, un prestataire ou un utilisateur métier puisse déposer et récupérer des fichiers sans tomber sur les répertoires système, sans voir les autres comptes, et sans faire n’importe quoi dans /etc ou /var.
Dans quels cas le chroot est vraiment utile
Le cas le plus parlant, c’est le SFTP. Vous avez un utilisateur qui doit envoyer des fichiers comptables, des exports ou des sauvegardes applicatives. Il n’a pas besoin d’un shell interactif, encore moins d’un accès large au serveur. Vous le chrootiez dans un dossier dédié, par exemple /data/client1, et son univers s’arrête là. Pour lui, ce dossier devient la racine.
On retrouve la même logique avec certains serveurs FTP, même si aujourd’hui SFTP est souvent préféré. Mentalement, c’est très simple : vous ne donnez pas les clés de la maison, vous ouvrez seulement le local de dépôt. C’est propre, lisible, et ça évite les confusions du genre utilisateur perdu dans des chemins qu’il ne comprend pas.
Le chroot peut aussi servir avec des comptes techniques qui doivent manipuler un jeu de fichiers précis. Il rend l’usage plus étroit, donc plus prévisible. Ce n’est pas seulement une question de sécurité pure. C’est aussi une manière de réduire le risque d’erreur humaine. Un utilisateur qui ne voit que son périmètre a moins de chances d’effacer le mauvais répertoire.
Pourquoi ce n’est pas une frontière de sécurité absolue
# vérifier les droits du dossier de chroot ls -ld /srv/sftp ls -ld /srv/sftp/monuser
C’est ici que beaucoup de gens vont trop vite. Un chroot n’est pas un conteneur moderne, ce n’est pas une machine virtuelle, et ce n’est pas une sandbox totale. Si un processus a des privilèges élevés ou si l’environnement chrooté est mal préparé, le niveau de protection réel peut être bien plus faible qu’on l’imagine.
Autrement dit, le chroot aide à enfermer une vue du système, mais il ne remplace pas une vraie politique de droits, ni SELinux, ni les permissions Unix, ni les contrôles applicatifs. Si vous laissez des binaires mal placés, des droits d’écriture là où il ne faut pas, ou si vous donnez un shell complet sans réfléchir aux dépendances et aux permissions, vous vous fabriquez un faux sentiment de sécurité.
Il faut aussi garder en tête qu’un service qui supporte le chroot ne l’implémente pas toujours de la même façon. Dans OpenSSH pour SFTP, par exemple, les règles de propriété sur les répertoires sont strictes pour une raison simple : si l’utilisateur peut modifier certains éléments de sa racine chrootée, l’isolement devient discutable.
Les erreurs fréquentes quand on veut chrooter un compte trop vite
L’erreur classique consiste à penser qu’il suffit de pointer un utilisateur vers son dossier personnel et que tout va marcher. En réalité, beaucoup de services refusent un chroot mal construit. Avec SFTP via SSH, le répertoire racine du chroot doit souvent appartenir à root et ne pas être inscriptible par l’utilisateur. Le compte doit écrire dans un sous-dossier, pas directement à la racine chrootée.
Autre erreur fréquente : vouloir fournir un shell complet dans un chroot minimal sans embarquer les bibliothèques, les commandes et l’environnement nécessaires. Résultat, l’utilisateur se connecte, puis tout casse de manière assez opaque. Une commande banale échoue, un shell ne se lance pas correctement, ou certains chemins attendus n’existent pas.
Il y a aussi le cas des permissions mal pensées. On veut enfermer un compte, mais on mélange propriété, groupes, ACL et besoins applicatifs sans plan clair. Le chroot devient alors pénible à maintenir, et chacun finit par ajouter des exceptions jusqu’à annuler l’intérêt de départ.
Le bon réflexe, c’est de partir du besoin réel. Est-ce qu’on veut un simple dépôt SFTP ? Un accès lecture seule ? Un compte qui dépose des fichiers dans un sous-répertoire précis ? Plus le besoin est net, plus le chroot reste propre. Dès qu’on essaie d’en faire un environnement polyvalent pour un utilisateur qui veut presque un vrai serveur, ça se complique très vite.
Le bon modèle mental pour ne pas se tromper
Le chroot fonctionne bien quand on l’utilise comme un couloir balisé, pas comme une forteresse parfaite. Pour un compte SFTP ou FTP, c’est souvent exactement ce qu’il faut. L’utilisateur arrive, voit uniquement son espace, dépose ses fichiers, repart. C’est clair pour lui, et c’est plus sain pour le serveur.
Si votre objectif est une isolation forte, il faut regarder plus loin : séparation stricte des droits, services dédiés, conteneurs, virtualisation, politiques SELinux, journalisation propre. Le chroot reste une brique utile, mais seulement une brique. Bien employé, il simplifie beaucoup de situations d’administration sous CentOS/Linux. Mal compris, il donne surtout l’impression d’avoir fermé la porte alors qu’une fenêtre est encore ouverte.