Permissions Linux : chmod, chown, sudo, ACL — tutoriel pas-à-pas

📍 Article principal du programme : Linux fondamentaux 2026 — commandes, services, dépannage
Ce tutoriel fait partie du programme « Linux fondamentaux ». Pour la vue d’ensemble, lisez d’abord le guide principal.

Introduction

Le modèle de permissions Unix est l’une des plus belles idées techniques des années 70 : neuf bits suffisent à décrire qui peut faire quoi sur n’importe quel fichier d’un système. Cinquante ans plus tard, ce modèle est toujours la base de Linux, macOS, FreeBSD, et il sert quotidiennement à isoler les utilisateurs, à durcir les services et à empêcher qu’un script bricolé n’efface la configuration d’un démon. Ce tutoriel vous fait passer de la lecture intuitive des permissions à leur manipulation maîtrisée, en couvrant chmod, chown, sudo, le bit setuid, le sticky bit et les ACL POSIX. À la fin, vous saurez auditer une arborescence, corriger un « Permission denied » sans casser autre chose, et sécuriser un répertoire applicatif sans copier-coller à l’aveugle.

Prérequis

• Une machine Linux avec un compte non root et l’accès sudo (Ubuntu 24.04/26.04 LTS, Debian 13, AlmaLinux 9, Rocky Linux 9).
• Connaissance de base de la ligne de commande (ls, cd, cat) — voir le tutoriel ligne de commande du programme si nécessaire.
• Niveau attendu : débutant à intermédiaire.
• Temps estimé : 90 minutes.

Étape 1 — Lire les permissions sur la sortie de ls

Avant de modifier quoi que ce soit, il faut savoir lire ce qu’on regarde. La commande ls -l est l’outil de référence pour cela. Elle affiche pour chaque entrée une ligne dont les dix premiers caractères encodent le type de fichier et les bits de permission. Un développeur expérimenté décode cette ligne en moins d’une seconde — un débutant qui n’apprend pas à le faire reste dépendant d’outils graphiques qui n’existent pas en SSH.

cd /tmp
touch fichier.txt
mkdir dossier
ln -s fichier.txt lien.txt
ls -l

La sortie ressemble à ceci :

-rw-r--r-- 1 malick malick    0 May  5 09:15 fichier.txt
drwxr-xr-x 2 malick malick 4096 May  5 09:15 dossier
lrwxrwxrwx 1 malick malick   11 May  5 09:15 lien.txt -> fichier.txt

Le tout premier caractère donne le type : - fichier régulier, d répertoire, l lien symbolique, c périphérique caractère, b périphérique bloc, s socket, p tube nommé. Les neuf caractères suivants se lisent par groupes de trois : propriétaire, groupe, autres. Chaque triplet code r (lecture), w (écriture), x (exécution pour un fichier ; traversée pour un répertoire). Sur un répertoire, le bit x ne signifie pas exécuter — il signifie « le droit d’entrer dedans » et de lister ses entrées si r est aussi présent. C’est l’incompréhension la plus fréquente des débutants : un répertoire sans x est inaccessible même si r est posé.

Étape 2 — Comprendre la notation octale

Linux propose deux notations pour écrire les permissions : la notation symbolique (u+w, g-r) et la notation octale (644, 755). Les deux donnent strictement le même résultat, mais la notation octale est devenue le standard de fait dans les scripts et la documentation parce qu’elle est compacte et sans ambiguïté.

L’idée est simple : chaque triplet de bits est interprété comme un nombre binaire, donc une valeur entre 0 et 7. r vaut 4, w vaut 2, x vaut 1, et on additionne. rwx donne donc 4+2+1=7, rw- donne 4+2=6, r-x donne 4+1=5, r-- donne 4. La permission 644 signifie « propriétaire rw, groupe r, autres r » — typique pour un fichier de configuration que tout le monde peut lire. La permission 755 signifie « propriétaire rwx, groupe rx, autres rx » — typique pour un script exécutable. La permission 600 ne donne rien à personne sauf au propriétaire — typique pour ~/.ssh/id_ed25519, et ssh refuse même de l’utiliser si elle est plus permissive.

stat -c "%a %n" /etc/ssh/sshd_config        # affiche : 644 /etc/ssh/sshd_config
stat -c "%a %n" ~/.ssh/id_ed25519           # doit afficher : 600 (sinon SSH refuse)
stat -c "%a %n" /usr/bin/ls                 # affiche : 755

La commande stat est le complément naturel de ls -l : elle affiche les permissions octales directement, sans qu’on ait à les compter. À retenir comme un mantra : 644 pour les fichiers de données, 755 pour les exécutables et les répertoires, 600 pour les secrets, 700 pour les répertoires privés. Quatre-vingt-dix pour cent des cas de production tiennent dans ces quatre valeurs.

Étape 3 — Modifier les permissions avec chmod

La commande chmod change les bits d’un fichier ou d’un répertoire. Elle accepte les deux notations. La notation symbolique est plus parlante pour les modifications ciblées (« j’ajoute le droit d’exécution au propriétaire »), la notation octale est plus pratique pour fixer un état complet (« je mets la permission à 644 »).

# Notation symbolique
chmod u+x script.sh                # ajoute le droit d'exécution au propriétaire
chmod g+w fichier.conf             # ajoute le droit d'écriture au groupe
chmod o-r secret.txt               # retire le droit de lecture aux autres
chmod a+r README.md                # ajoute le droit de lecture à tous (a = all)
chmod ug=rw,o= journal.log         # définit propriétaire/groupe rw, autres rien

# Notation octale
chmod 644 /etc/mon-app/config.yml
chmod 755 /opt/mon-app/run.sh
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

# Récursif sur un répertoire
chmod -R 755 /var/www/site/

Après chaque chmod, vérifiez avec ls -l ou stat que la permission est bien celle attendue. Le mode récursif -R est puissant et dangereux : il pose la même permission sur fichiers et répertoires, ce qui pose problème puisque les répertoires ont besoin du bit x que les fichiers de données ne devraient pas avoir. Pour traiter fichiers et répertoires différemment, utilisez find :

find /var/www/site -type d -exec chmod 755 {} \;       # répertoires
find /var/www/site -type f -exec chmod 644 {} \;       # fichiers

Cette construction parcourt l’arborescence, applique 755 aux répertoires (rwxr-xr-x) et 644 aux fichiers (rw-r–r–). C’est la combinaison standard pour un site web statique servi par Nginx ou Apache. Pour les fichiers exécutables précis (un script de déploiement, par exemple), on remet ensuite chmod 755 script.sh à la main.

Étape 4 — Changer le propriétaire avec chown et chgrp

Les permissions ne sont qu’une moitié du modèle ; l’autre moitié, c’est l’identité. Chaque fichier appartient à un utilisateur et à un groupe, et c’est cette appartenance qui détermine quel triplet de bits s’applique quand quelqu’un demande l’accès. La commande chown change le propriétaire et éventuellement le groupe ; chgrp change uniquement le groupe.

sudo chown www-data /var/www/site/index.html              # change le propriétaire
sudo chown www-data:www-data /var/www/site/index.html     # change propriétaire ET groupe
sudo chown :developers /opt/projets/                      # change uniquement le groupe
sudo chown -R deploy:deploy /opt/mon-app/                 # récursif

Après un déploiement, l’erreur la plus courante consiste à laisser des fichiers appartenir à root alors qu’ils devraient appartenir au compte de service (www-data pour Nginx, nginx pour la version RHEL, deploy pour un utilisateur applicatif). Le service tente d’écrire un cache, ne peut pas, échoue silencieusement ou bruyamment selon la qualité du log. Le réflexe correct : après scp, rsync ou git clone en root, exécuter immédiatement chown -R vers le bon utilisateur, puis vérifier avec ls -l. Pour appartenir à plusieurs groupes, un utilisateur peut être ajouté à un groupe secondaire via sudo usermod -aG groupe utilisateur ; il devra ouvrir une nouvelle session pour que le groupe soit pris en compte.

Étape 5 — Élever les droits avec sudo (proprement)

La règle d’or sur un serveur Linux est de ne jamais travailler en root par défaut. Vous vous connectez avec un compte personnel, vous administrez avec un compte personnel, et vous escaladez ponctuellement vers root pour des opérations qui le justifient. C’est le rôle de sudo : il exécute une commande avec les droits d’un autre utilisateur (root par défaut), à condition que l’appelant figure dans /etc/sudoers ou dans un groupe autorisé.

sudo apt update                                  # exécute apt update en root
sudo -u postgres psql                            # exécute psql sous l'utilisateur postgres
sudo -i                                          # ouvre un shell root interactif
sudo visudo                                      # édite /etc/sudoers en mode protégé
sudo -l                                          # liste ce que je suis autorisé à faire

Trois pratiques durcissent rapidement la sécurité. Premièrement, ajoutez votre compte au groupe sudo (Debian/Ubuntu) ou wheel (Alma/Rocky) plutôt que d’écrire des règles individuelles dans sudoers. Deuxièmement, utilisez sudo visudo pour éditer la configuration : la commande vérifie la syntaxe avant de sauvegarder, ce qui évite de se retrouver bloqué hors du système avec un sudoers cassé. Troisièmement, configurez Defaults timestamp_timeout=15 pour que le ticket sudo dure 15 minutes maximum — au-delà, la commande exige à nouveau le mot de passe. Pour des automatisations, créez un compte de service dédié avec une règle sudoers ciblée comme deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart mon-app, qui n’autorise qu’un redémarrage précis sans mot de passe et rien d’autre.

Étape 6 — Comprendre setuid, setgid, sticky bit

Au-delà des neuf bits classiques, trois bits spéciaux modifient le comportement d’un fichier. Le bit setuid sur un binaire le fait s’exécuter avec les droits du propriétaire, pas de l’appelant. Le bit setgid fait pareil pour le groupe ; sur un répertoire, il a un autre effet : tout fichier créé dedans hérite du groupe du répertoire, pratique pour les répertoires partagés. Le sticky bit sur un répertoire empêche un utilisateur de supprimer les fichiers d’un autre, même s’il a le droit d’écrire dans le répertoire — c’est la protection appliquée à /tmp.

ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd
#    ^^ le 's' signale setuid : passwd s'exécute toujours en root

ls -ld /tmp
# drwxrwxrwt 12 root root 4096 ... /tmp
#         ^^ le 't' final signale le sticky bit

chmod u+s binaire                # active setuid
chmod g+s repertoire             # active setgid sur un répertoire
chmod +t /shared/repo            # active le sticky bit
chmod 4755 binaire               # notation octale, le 4 préfixe = setuid
chmod 2755 repertoire            # le 2 préfixe = setgid
chmod 1777 /shared/tmp           # le 1 préfixe = sticky

Le bit setuid est extrêmement puissant et donc extrêmement dangereux. Un binaire setuid root mal écrit qui exécute une commande externe sans neutraliser $PATH, ou qui charge une bibliothèque depuis un chemin contrôlé par l’appelant, devient un vecteur d’élévation de privilèges. La règle de prudence en 2026 : ne posez jamais setuid root sur un script ou un binaire que vous n’avez pas écrit et audité ; préférez sudo avec une règle ciblée, ou un service systemd avec PolicyKit. Pour auditer les binaires setuid d’un système, find / -perm -u=s -type f 2>/dev/null donne la liste — utile à comparer entre deux serveurs supposément identiques.

Étape 7 — Étendre le modèle avec les ACL POSIX

Le modèle propriétaire/groupe/autres est élégant mais limité : si vous voulez accorder l’accès en lecture à deux utilisateurs précis sur un fichier, sans inclure tout un groupe, vous êtes coincé. Les Access Control Lists POSIX, supportées par tous les systèmes de fichiers Linux modernes (ext4, XFS, Btrfs), comblent ce trou. La syntaxe ressemble à setfacl -m u:utilisateur:rw fichier.

getfacl /opt/donnees/rapport.csv                 # affiche les ACL effectives
sudo setfacl -m u:alice:rw /opt/donnees/rapport.csv     # accorde à alice rw
sudo setfacl -m g:auditeurs:r /opt/donnees/rapport.csv  # accorde au groupe auditeurs r
sudo setfacl -x u:alice /opt/donnees/rapport.csv        # retire l'ACL d'alice
sudo setfacl -b /opt/donnees/rapport.csv                # retire toutes les ACL

Quand un fichier porte des ACL, ls -l affiche un signe + à la fin de la chaîne de permissions : -rw-r--r--+. C’est le seul indice visible — sans getfacl, on peut tomber dans le piège de croire que le fichier a les permissions affichées par ls alors qu’en réalité un autre utilisateur a un accès supplémentaire. Sur un serveur de production qui mélange plusieurs équipes, le réflexe d’auditer les ACL est aussi important que celui d’auditer les bits. Pour les répertoires, setfacl -d -m définit des ACL par défaut héritées par tout nouveau fichier créé dedans — outil précieux pour les espaces partagés.

Étape 8 — Vérification et bonnes habitudes

Après cette traversée, validez votre maîtrise par un mini-scénario réel : créer un répertoire applicatif sécurisé pour un service Node fictif. La séquence ci-dessous reproduit ce qu’on fait à chaque déploiement sur un VPS.

sudo useradd -r -s /usr/sbin/nologin -d /opt/mon-app -m mon-app
sudo mkdir -p /opt/mon-app/{bin,data,logs,config}
sudo chown -R mon-app:mon-app /opt/mon-app
sudo chmod 750 /opt/mon-app
sudo chmod 700 /opt/mon-app/data
sudo chmod 750 /opt/mon-app/bin
sudo chmod 644 /opt/mon-app/config/*.yml 2>/dev/null || true
sudo chmod 600 /opt/mon-app/config/secrets.env 2>/dev/null || true
sudo find /opt/mon-app -type f -name "*.sh" -exec chmod 750 {} \;
ls -laR /opt/mon-app | head -30

La sortie attendue montre l’utilisateur mon-app partout, le répertoire data à 700 (privé), les configs lisibles à 644, les secrets verrouillés à 600, et les scripts exécutables par le propriétaire et son groupe. Cette discipline — utilisateur dédié, répertoires segmentés, secrets isolés — est ce qui distingue une installation amateur d’une installation digne d’audit. Reproduisez le pattern pour chaque service que vous déployez ; en six mois, ce sera devenu un automatisme.

Erreurs fréquentes

Tutoriels associés

• Ligne de commande Linux : tutoriel pas-à-pas 2026
• SSH : clés, config, tunnels et hardening

Pour explorer plus loin

• 🔝 Retour au guide principal : Linux fondamentaux 2026
• Pages de manuel : man chmod, man chown, man sudoers, man acl.
• Documentation Linux Foundation FHS 3.0 — refspecs.linuxfoundation.org/fhs.shtml
• Guide CIS Benchmarks Ubuntu — cisecurity.org/benchmark/ubuntu_linux
• Sudo official documentation — sudo.ws/docs/man/sudoers.man

FAQ

Pourquoi ne pas utiliser chmod 777 pour faire taire un « Permission denied » ?
Parce que 777 ouvre l’écriture à tout le monde, y compris à un attaquant qui aurait pris le contrôle d’un autre service. C’est l’équivalent de laisser sa porte ouverte pour ne plus avoir à chercher ses clés. La bonne approche est de comprendre quel utilisateur essaie d’accéder, et d’ajuster propriétaire ou groupe. strace -f -e openat commande 2>&1 | grep EACCES trace les appels système qui échouent et révèle exactement quel fichier pose problème.

Quelle différence entre groupe primaire et groupe secondaire ?
Chaque utilisateur a un et un seul groupe primaire (visible dans /etc/passwd) qui devient le propriétaire de groupe par défaut des fichiers qu’il crée. Il peut appartenir à plusieurs groupes secondaires (visibles dans /etc/group) qui lui donnent des droits supplémentaires. id liste les groupes effectifs de la session courante, groups utilisateur liste tous les groupes d’un utilisateur.

Pourquoi sudo demande mon mot de passe et pas celui de root ?
C’est la conception même de sudo : on prouve qu’on est bien soi-même, et le système consulte ensuite /etc/sudoers pour décider si on a le droit d’exécuter la commande demandée en tant que root. Ce mécanisme évite de partager le mot de passe root entre administrateurs et trace dans les logs qui a fait quoi en root, ce que su ne permet pas.

Comment retrouver les fichiers world-writable d’un système ?
La commande sudo find / -xdev -type f -perm -o+w 2>/dev/null liste tous les fichiers où le bit d’écriture pour « autres » est posé. Sur un serveur sain, cette liste est très courte — à peine quelques fichiers de socket ou de cache. Une longue liste indique un déploiement bâclé qui mérite un audit.

Les permissions ext4/XFS s’appliquent-elles aussi aux conteneurs Docker ?
Oui, le système de fichiers du conteneur est en général un overlay ext4. Les bits de permission s’appliquent comme sur un système classique, mais avec deux subtilités : l’utilisateur 1000 dans le conteneur n’est pas forcément l’utilisateur 1000 sur l’hôte, et le bit setuid peut être désactivé selon la configuration du runtime. Pour des conteneurs sécurisés, l’option --user de Docker et la directive USER dans le Dockerfile imposent une exécution non root, ce qui limite l’impact d’une faille applicative.

Comment automatiser un audit régulier des permissions critiques ?
Un script lancé par un timer systemd hebdomadaire suffit : il vérifie les permissions de quelques chemins sensibles (/etc/sudoers doit être 440, /etc/shadow doit être 640, /root doit être 700), compare avec un état attendu, et envoie un courriel si une dérive est détectée. Pour creuser ce sujet, auditd (paquet auditd) trace les modifications en temps réel et écrit les changements de permission dans /var/log/audit/audit.log.