Permissions fichiers Linux : comprendre chmod et chown

Après plus de dix ans à administrer des serveurs Linux pour des projets web, je peux vous affirmer que la gestion des permissions est l’un des sujets les plus fondamentaux et pourtant les plus mal compris. Combien de fois ai-je vu des développeurs appliquer un chmod 777 par réflexe pour « résoudre » un problème d’accès, sans mesurer les risques de sécurité que cela implique ? Trop souvent.

Dans ce guide, je vous explique en détail comment fonctionnent les permissions sous Linux, comment utiliser correctement chmod et chown, et surtout comment appliquer les bonnes pratiques que j’ai forgées au fil des années. Que vous soyez administrateur système débutant ou développeur qui déploie ses applications, ce guide vous donnera les bases solides pour ne plus jamais tâtonner devant un problème de droits.

Comprendre le système de permissions Linux

Le système de permissions Linux repose sur un principe simple mais puissant : chaque fichier et chaque répertoire possède un propriétaire, un groupe et des droits d’accès définis pour trois catégories d’utilisateurs. Ce modèle, hérité d’Unix, est documenté en détail dans la page de manuel officielle chmod et constitue la base de la sécurité locale de tout système Linux.

Les trois catégories d’utilisateurs sont :

• Propriétaire (user, u) : l’utilisateur qui possède le fichier, généralement celui qui l’a créé
• Groupe (group, g) : les utilisateurs qui appartiennent au groupe associé au fichier
• Autres (others, o) : tous les autres utilisateurs du système

Pour chaque catégorie, trois types de droits peuvent être attribués :

• Lecture (read, r) : permet de lire le contenu du fichier ou de lister le contenu d’un répertoire
• Écriture (write, w) : permet de modifier le fichier ou d’ajouter/supprimer des fichiers dans un répertoire
• Exécution (execute, x) : permet d’exécuter un fichier ou de traverser un répertoire

Ce système offre donc 9 bits de permissions au total (3 droits × 3 catégories), ce qui permet un contrôle fin des accès. Dans ma pratique quotidienne, je constate que la maîtrise de ce modèle suffit à couvrir 95 % des besoins en sécurité locale d’un serveur. Si vous travaillez sur des environnements conteneurisés, vous retrouverez ces mêmes principes : j’en parle d’ailleurs dans mon article sur Kubernetes ou Docker : lequel choisir en 2026.

Lire les permissions d’un fichier avec ls -l

Avant de modifier quoi que ce soit, il faut savoir lire les permissions actuelles. La commande ls -l affiche les informations détaillées d’un fichier :

$ ls -l index.html
-rw-r--r-- 1 thomas www-data 4096 mai 10 14:30 index.html

Décortiquons cette sortie. Le premier caractère indique le type de fichier : un tiret (-) pour un fichier ordinaire, d pour un répertoire, l pour un lien symbolique. Les neuf caractères suivants représentent les permissions, groupées par trois :

• rw- : le propriétaire (thomas) peut lire et écrire, mais pas exécuter
• r-- : le groupe (www-data) peut uniquement lire
• r-- : les autres utilisateurs peuvent uniquement lire

Le nombre 1 indique le nombre de liens physiques, suivi du nom du propriétaire, du nom du groupe, de la taille en octets, de la date de modification et enfin du nom du fichier. En une seule commande, vous avez toutes les informations nécessaires pour comprendre qui peut faire quoi sur ce fichier.

Pour visualiser les permissions sous forme numérique (octale), j’utilise souvent la commande stat :

$ stat -c '%a %n' index.html
644 index.html

Ce 644 est la représentation octale des permissions rw-r--r--. C’est cette notation que nous allons approfondir dans la section suivante.

Chmod : modifier les droits d’accès

La commande chmod (change mode) est l’outil principal pour modifier les permissions d’un fichier ou d’un répertoire. Elle accepte deux syntaxes : la notation symbolique et la notation octale.

La notation symbolique

La notation symbolique utilise des lettres et des opérateurs pour ajouter, retirer ou définir des permissions :

# Ajouter l'exécution pour le propriétaire
$ chmod u+x script.sh

# Retirer l'écriture pour le groupe et les autres
$ chmod go-w fichier.txt

# Définir exactement les permissions pour tous
$ chmod u=rwx,g=rx,o=r fichier.txt

Les opérateurs sont + (ajouter), - (retirer) et = (définir exactement). Cette syntaxe est très lisible et je la recommande quand vous devez modifier une seule permission sans toucher aux autres.

La notation octale

La notation octale représente chaque groupe de permissions par un chiffre de 0 à 7. Chaque droit a une valeur :

• Lecture (r) = 4
• Écriture (w) = 2
• Exécution (x) = 1

On additionne les valeurs pour obtenir le chiffre correspondant. Par exemple, rwx = 4 + 2 + 1 = 7, et r-x = 4 + 0 + 1 = 5. Ainsi, chmod 755 signifie : propriétaire = rwx (7), groupe = r-x (5), autres = r-x (5).

Voici les combinaisons les plus courantes que j’utilise au quotidien :

# Fichier accessible en lecture seule par tous
$ chmod 644 fichier.txt

# Script exécutable par le propriétaire
$ chmod 755 script.sh

# Fichier privé, accessible uniquement par le propriétaire
$ chmod 700 fichier-prive.conf

# Répertoire partagé en lecture
$ chmod 755 /var/www/html/

L’option récursive

Pour appliquer des permissions à un répertoire et tout son contenu, on utilise l’option -R :

$ chmod -R 755 /var/www/html/mon-site/

Attention : appliquer les mêmes permissions aux fichiers et aux répertoires est rarement souhaitable. Les répertoires ont besoin du droit d’exécution pour être traversés, mais les fichiers standards n’en ont généralement pas besoin. Je vous recommande d’utiliser la commande find pour différencier :

# 755 pour les répertoires
$ find /var/www/html/ -type d -exec chmod 755 {} \;

# 644 pour les fichiers
$ find /var/www/html/ -type f -exec chmod 644 {} \;

Cette distinction est particulièrement importante pour la sécurité de vos déploiements web. J’en applique systématiquement le principe sur tous mes projets, y compris lorsque je travaille avec des outils de versioning Docker pour mes conteneurs.

Chown : changer le propriétaire et le groupe

La commande chown (change owner) modifie le propriétaire et/ou le groupe d’un fichier. C’est un outil complémentaire à chmod : là où chmod définit ce que chaque catégorie peut faire, chown définit qui appartient à quelle catégorie.

# Changer le propriétaire
$ chown thomas fichier.txt

# Changer le propriétaire et le groupe
$ chown thomas:www-data fichier.txt

# Changer uniquement le groupe
$ chown :www-data fichier.txt

# Récursivement sur un répertoire
$ chown -R thomas:www-data /var/www/html/mon-site/

Un point essentiel à retenir : seul root peut exécuter chown pour attribuer un fichier à un autre utilisateur. C’est une mesure de sécurité fondamentale sous Linux ; sans cela, n’importe quel utilisateur pourrait s’attribuer des fichiers sensibles. La documentation GNU Coreutils de chown détaille l’ensemble des options disponibles.

En pratique, sur un serveur web, j’utilise très souvent chown pour attribuer les fichiers au bon utilisateur tout en associant le groupe du serveur web :

# Configuration typique pour Apache/Nginx
$ chown -R deployer:www-data /var/www/html/
$ chmod -R 750 /var/www/html/

Cette combinaison permet à l’utilisateur deployer de modifier les fichiers, au serveur web (via le groupe www-data) de les lire et les exécuter, et bloque tout accès aux autres utilisateurs. C’est une configuration que je considère comme le minimum de sécurité pour tout hébergement web professionnel. Pour aller plus loin sur la sécurité de vos projets en ligne, je vous invite à consulter mon article sur l’expertise cybersécurité.

Tableau comparatif chmod vs chown

Pour bien distinguer les deux commandes, voici un résumé de leurs différences et complémentarités :

En résumé : chown définit les acteurs, chmod définit les actions. Les deux commandes se complètent et sont presque toujours utilisées ensemble lors de la configuration d’un serveur ou d’un déploiement.

Permissions courantes pour un serveur web

Après des années à configurer des serveurs pour des sites WordPress, Symfony et d’autres applications PHP, j’ai établi un ensemble de permissions standards qui couvrent la grande majorité des cas. Si vous hésitez entre différentes solutions pour votre site, mon comparatif WordPress vs Wix vs Squarespace vs Webflow peut vous aider à choisir.

Pour WordPress spécifiquement, voici la configuration que j’applique systématiquement :

# Définir le propriétaire
$ chown -R www-data:www-data /var/www/html/wordpress/

# Répertoires
$ find /var/www/html/wordpress/ -type d -exec chmod 755 {} \;

# Fichiers
$ find /var/www/html/wordpress/ -type f -exec chmod 644 {} \;

# wp-config.php (fichier sensible)
$ chmod 640 /var/www/html/wordpress/wp-config.php

# Répertoire uploads (écriture nécessaire)
$ chmod -R 775 /var/www/html/wordpress/wp-content/uploads/

Le fichier wp-config.php mérite une attention particulière car il contient les identifiants de la base de données. Un chmod 640 garantit que seul le propriétaire peut le modifier et que le serveur web (via le groupe) peut le lire sans qu’aucun autre utilisateur n’y ait accès. Cette attention à la sécurité rejoint les préoccupations que j’aborde dans mon article sur les emplois en cybersécurité.

Bits spéciaux : SUID, SGID et sticky bit

Au-delà des 9 bits de permissions classiques, Linux propose trois bits spéciaux qui modifient le comportement des fichiers et répertoires. Ces bits sont représentés par un quatrième chiffre placé devant la notation octale habituelle.

SUID (Set User ID) : valeur 4

Lorsque le bit SUID est activé sur un fichier exécutable, celui-ci s’exécute avec les permissions de son propriétaire plutôt que celles de l’utilisateur qui le lance. L’exemple le plus courant est la commande passwd :

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 mai  3 14:30 /usr/bin/passwd

Le s à la place du x du propriétaire indique le SUID. Cela permet à n’importe quel utilisateur de modifier son propre mot de passe en écrivant dans /etc/shadow, un fichier que seul root peut modifier directement.

# Activer le SUID
$ chmod u+s programme
$ chmod 4755 programme

SGID (Set Group ID) : valeur 2

Sur un fichier exécutable, le SGID fonctionne comme le SUID mais pour le groupe. Sur un répertoire, c’est plus intéressant : tous les fichiers créés dans ce répertoire héritent du groupe du répertoire plutôt que du groupe primaire de l’utilisateur. C’est extrêmement utile pour les répertoires de travail partagés.

# Créer un répertoire de projet partagé
$ mkdir /var/www/projet-equipe
$ chown :dev-team /var/www/projet-equipe
$ chmod 2775 /var/www/projet-equipe

Avec cette configuration, chaque fichier créé dans ce répertoire appartiendra automatiquement au groupe dev-team, facilitant le travail collaboratif. Ce genre de configuration est fréquent dans les environnements Git, GitHub et GitLab partagés.

Sticky bit : valeur 1

Le sticky bit, appliqué à un répertoire, empêche les utilisateurs de supprimer les fichiers des autres, même s’ils ont le droit d’écriture sur le répertoire. L’exemple classique est /tmp :

$ ls -ld /tmp
drwxrwxrwt 18 root root 4096 mai 10 14:30 /tmp

Le t à la fin indique le sticky bit. Tout le monde peut écrire dans /tmp, mais chacun ne peut supprimer que ses propres fichiers. Selon la documentation des permissions UNIX sur Wikipédia, ce mécanisme est hérité des premières versions d’Unix et reste fondamental pour la sécurité des répertoires partagés.

# Activer le sticky bit
$ chmod +t /repertoire-partage
$ chmod 1777 /repertoire-partage

Erreurs fréquentes et bonnes pratiques

Au fil de mes années d’expérience, j’ai identifié plusieurs erreurs récurrentes que je vois commettre, parfois même par des développeurs expérimentés. Voici les pièges à éviter et les bonnes pratiques à adopter.

Erreur n°1 : le chmod 777 systématique

C’est le réflexe le plus dangereux. Un chmod 777 donne tous les droits à tout le monde : lecture, écriture et exécution. Sur un serveur web, cela signifie que n’importe quel processus ou utilisateur peut modifier vos fichiers. Si une faille est exploitée, l’attaquant a un accès total. La recommandation officielle de la CNIL sur la sécurité des données insiste sur le principe du moindre privilège, qui s’applique directement aux permissions de fichiers.

La règle d’or : appliquez toujours le principe du moindre privilège. Accordez uniquement les permissions strictement nécessaires au bon fonctionnement de votre application.

Erreur n°2 : ignorer les différences fichiers/répertoires

Un chmod -R 644 sur un répertoire rendra tous les sous-répertoires inaccessibles, car sans le droit d’exécution (x), on ne peut pas traverser un répertoire. Utilisez toujours find pour différencier les types comme je l’ai montré plus haut.

Erreur n°3 : ne pas vérifier le propriétaire

Modifier les permissions ne suffit pas si le propriétaire du fichier n’est pas le bon. Après un déploiement ou une copie de fichiers, vérifiez toujours le propriétaire avec ls -la et ajustez avec chown si nécessaire.

Erreur n°4 : oublier les fichiers sensibles

Les fichiers contenant des informations sensibles (fichiers .env, clés SSH, certificats SSL, fichiers de configuration avec des mots de passe) doivent avoir des permissions strictes : 600 ou 640 maximum. J’ai vu des clés privées SSH en 644 sur des serveurs de production ; c’est une invitation aux intrusions. Pour bien comprendre les enjeux, consultez les solutions proposées par Nomios Paris en matière de cybersécurité.

Mes bonnes pratiques

• Documentez vos choix de permissions dans un script de déploiement
• Utilisez des groupes Unix plutôt que d’ouvrir les permissions aux « others »
• Intégrez la vérification des permissions dans vos pipelines CI/CD, un sujet que j’aborde également dans mon guide sur l’alternance DevOps
• Utilisez umask pour définir les permissions par défaut des fichiers créés
• Effectuez des audits réguliers avec find / -perm -4000 pour repérer les fichiers SUID

# Vérifier le umask actuel
$ umask
0022

# Un umask de 0022 signifie :
# Fichiers créés avec 644 (666 - 022)
# Répertoires créés avec 755 (777 - 022)

# Pour un environnement plus restrictif
$ umask 0027
# Fichiers créés avec 640 (666 - 027)
# Répertoires créés avec 750 (777 - 027)

Ces pratiques s’inscrivent dans une démarche globale de sécurité. Que vous gériez un simple blog WordPress ou une infrastructure complexe avec Kubernetes et Docker, les permissions restent votre première ligne de défense.