FlowingDev

Chmod, expliqué : la poignée de main secrète de vos fichiers et dossiers

Comprendre les permissions de fichiers Unix, le système de droits de lecture, écriture et exécution qui protège les fichiers et répertoires sur Linux, macOS et les serveurs web.

Essayer l'outil: Calculatrice Chmod

En une phrase

chmod est la commande Unix qui définit qui peut lire un fichier, y écrire ou l'exécuter. C'est le système de contrôle d'accès fondamental pour la majorité des serveurs et des postes de développeur dans le monde.

Le problème que ça résout

Imaginez les débuts de l'informatique : une personne, une machine, une tâche à la fois. Sur un tel système, les permissions de fichiers sont une solution en quête d'un problème. Si vous êtes la seule personne à jamais utiliser l'ordinateur, de qui protégez-vous les fichiers ? De vous-même ?

Puis est arrivé Unix à la fin des années 1960, aux Bell Labs. Son idée révolutionnaire était d'être un système d'exploitation multi-utilisateur et multitâche dès sa conception. Soudain, plusieurs programmeurs se sont retrouvés connectés au même ordinateur central (le mainframe) via différents terminaux, travaillant tous en même temps. Cela a créé un nouveau problème urgent : comment empêcher Dennis de supprimer accidentellement (ou "accidentellement") le nouveau compilateur C de Ken ? Comment permettre à votre partenaire de projet de lire votre code mais l'empêcher de le modifier ? Comment protéger les fichiers essentiels du système d'exploitation d'un stagiaire gaffeur ?

La solution fut un système de propriété et de permissions d'une simplicité et d'une robustesse magnifiques, intégré au système de fichiers lui-même. Chaque fichier et répertoire aurait un propriétaire, appartiendrait à un groupe et disposerait d'un ensemble de permissions spécifiques pour trois classes d'utilisateurs : le propriétaire, les membres du groupe, et tous les autres.

La commande pour « changer le mode » d'un fichier — c'est-à-dire, pour modifier ces permissions — fut nommée chmod. Elle est devenue l'outil universel pour les administrateurs système et les utilisateurs pour déclarer : « Ce fichier est à moi, et voici les règles pour interagir avec. » Elle a résolu le problème du chaos multi-utilisateur avec une telle efficacité que le même modèle de base est encore utilisé aujourd'hui sur pratiquement tous les serveurs Linux, machines macOS, téléphones Android et objets connectés (IoT) de la planète.

Comment ça marche sous le capot

Au fond, le système chmod est une grille de règles de 3x3, avec quelques options spéciales pour le style. Pour le piger, il faut comprendre les trois types de permissions et les trois classes d'utilisateurs auxquelles elles peuvent s'appliquer.

Les trois permissions : Read, Write, Execute

Tout tourne autour de trois actions de base que vous pouvez effectuer sur un fichier ou un répertoire. Elles sont représentées par les lettres r, w et x.

  • Read (r) : La capacité d'ouvrir et de voir le contenu d'un fichier.
  • Write (w) : La capacité de modifier, changer ou supprimer le contenu d'un fichier.
  • Execute (x) : La capacité de lancer le fichier comme un programme ou un script.

Mais voici le premier piège : ces permissions ont une signification légèrement différente pour un répertoire. C'est un point de confusion super courant.

Permission Sur un fichier Sur un répertoire
Read (r) Peut voir le contenu du fichier Peut lister les noms des fichiers dans le répertoire (ls)
Write (w) Peut changer le contenu du fichier Peut créer, renommer ou supprimer des fichiers dans le répertoire
Execute (x) Peut lancer le fichier Peut entrer dans le répertoire (cd) et accéder aux fichiers qu'il contient

Pensez à ce dernier point. Si un répertoire n'a pas la permission d'exécution pour vous, vous ne pouvez pas faire cd dedans, même si vous pouvez voir son contenu ! Vous avez besoin de x pour passer la « porte » du répertoire.

Les trois classes d'utilisateurs : Propriétaire, Groupe, Autres

Les permissions Unix ne sont pas universelles ; elles sont assignées à des catégories spécifiques d'utilisateurs.

  • Owner (u) : L'unique utilisateur qui possède le fichier. En général, c'est la personne qui l'a créé. Le propriétaire a le plus de contrôle.
  • Group (g) : Chaque fichier appartient à un groupe. Cela permet au propriétaire de partager l'accès avec des membres spécifiques de l'équipe. Par exemple, tous les fichiers du « Projet Apollo » pourraient appartenir au groupe apollo-devs.
  • Others (o) : Littéralement tout le monde. Tout utilisateur sur le système qui n'est ni le propriétaire ni membre du groupe du fichier.

Quand vous voyez une chaîne de permissions comme rwxr-xr--, il s'agit en fait de trois ensembles de permissions rwx collés les uns aux autres pour le Propriétaire, le Groupe et les Autres, dans cet ordre.

  • rwx : Le Propriétaire peut lire, écrire et exécuter.
  • r-x : Le Groupe peut lire et exécuter, mais pas écrire.
  • r-- : Les Autres peuvent seulement lire.

Les deux notations : Symbolique vs. Octale

Il y a deux façons de dire à chmod ce que vous voulez, et les développeurs passent leur temps à traduire de l'une à l'autre.

1. Notation Symbolique (la méthode « sympa ») La notation symbolique utilise les lettres que nous avons déjà apprises (r, w, x et u, g, o, a où a signifie « tous »). On utilise + pour ajouter une permission, - pour la retirer, et = pour la définir de manière exacte.

# Donner la permission d'exécution au propriétaire
$ chmod u+x mon_script.sh

# Retirer la permission d'écriture pour le groupe et les autres
$ chmod go-w donnees_sensibles.txt

# Définir les permissions exactes : le proprio peut lire/écrire, le groupe peut lire, les autres n'ont aucun accès
$ chmod u=rw,g=r,o= config.yml

C'est super pour faire de petits changements ciblés.

2. Notation Octale (la méthode « nerd ») La notation octale est plus rapide, plus courante dans les scripts, et basée sur le binaire. Chaque permission (r, w, x) est un bit dans un nombre à 3 bits.

  • r (read) est le premier bit, avec une valeur de 4.
  • w (write) est le deuxième bit, avec une valeur de 2.
  • x (execute) est le troisième bit, avec une valeur de 1.

Vous additionnez les nombres pour obtenir les permissions que vous voulez.

Nombre Binaire (rwx) Permissions accordées
0 000 (---) Aucune
1 001 (--x) Exécution
2 010 (-w-) Écriture
3 011 (-wx) Écriture et exécution
4 100 (r--) Lecture
5 101 (r-x) Lecture et exécution
6 110 (rw-) Lecture et écriture
7 111 (rwx) Lecture, écriture, exécution

Un code octal à trois chiffres comme 755 représente les permissions pour le Propriétaire, le Groupe et les Autres.

chmod 755 mon_script.sh signifie :

  • Propriétaire : 7 (rwx) - Lecture, écriture et exécution.
  • Groupe : 5 (r-x) - Lecture et exécution.
  • Autres : 5 (r-x) - Lecture et exécution.

C'est une permission très courante pour les scripts exécutables qui peuvent être lancés sans risque par d'autres. Une permission courante pour un fichier est 644 (le propriétaire peut lire/écrire, tous les autres peuvent seulement lire).

Les invités spéciaux : SUID, SGID et le Sticky Bit

Au-delà des basiques rwx, il existe trois modes spéciaux, représentés par un quatrième chiffre octal au début (par ex., chmod 4755).

  • SUID (Set User ID) - Octal 4 : Lorsqu'un fichier exécutable avec ce bit est lancé, il s'exécute avec les permissions du propriétaire du fichier, et non de l'utilisateur qui l'a lancé. L'exemple classique est la commande passwd, qui doit modifier le fichier protégé /etc/shadow. L'exécutable passwd appartient à root et a le bit SUID activé, donc quand un utilisateur normal le lance, il obtient temporairement les privilèges de root juste pour cette unique opération. C'est puissant mais dangereux.
  • SGID (Set Group ID) - Octal 2 : Similaire au SUID, mais un exécutable se lance avec l'identité du groupe du fichier. Plus utile encore, lorsqu'il est défini sur un répertoire, tout nouveau fichier ou répertoire créé à l'intérieur héritera automatiquement du groupe du répertoire parent, et non du groupe principal de l'utilisateur créateur. C'est essentiel pour les dossiers de projet partagés.
  • Sticky Bit - Octal 1 : Celui-ci a une histoire étrange, mais aujourd'hui il est presque exclusivement utilisé sur les répertoires. Quand un répertoire a le sticky bit (comme le dossier système /tmp), tous les utilisateurs peuvent y créer des fichiers, mais un utilisateur ne peut supprimer ou renommer que les fichiers qu'il possède lui-même. Ça empêche les gens de toucher aux affaires des autres dans un espace partagé.

Histoires vécues

Le cas du script qui ne voulait pas se lancer

Alex, un développeur junior, écrit un brillant script shell pour automatiser le déploiement sur un serveur. Il commite deploy.sh sur Git. Sur le serveur de production, il clone le dépôt, tape ./deploy.sh et appuie sur Entrée. La réponse : bash: ./deploy.sh: Permission denied. Panique. A-t-il cassé le serveur ? Un développeur senior tape calmement ls -l deploy.sh et lui montre la sortie : -rw-r--r--. Le fichier avait les permissions de lecture et d'écriture, mais pas d'exécution (x). Git ne conserve pas les permissions d'exécution par défaut. Un rapide chmod +x deploy.sh plus tard, le script s'est exécuté parfaitement. Leçon : Les fichiers, surtout ceux provenant de sources comme Git ou des archives zip, ne sont pas exécutables par défaut. Vous devez explicitement leur donner la permission d'être lancés.

Le cauchemar du dossier de projet partagé

Une équipe de designers et une équipe de développeurs devaient partager des ressources dans un dossier sur un serveur Linux : /data/project-x. L'admin sys a mis tout le monde dans le groupe project-x-team et a donné au groupe le droit d'écriture sur le dossier. Mais le chaos s'est installé. Quand un designer envoyait un fichier, il appartenait à designer:designers, et les développeurs ne pouvaient pas le modifier. Quand un développeur créait un sous-dossier, il appartenait à dev:developers, et les designers ne pouvaient pas y ajouter de fichiers. Tout le monde demandait constamment à l'admin sys de corriger les permissions. La solution ? L'admin a lancé chmod g+s /data/project-x. Cela a activé le bit SGID sur le répertoire. À partir de ce moment, chaque nouveau fichier et dossier créé dans /data/project-x a automatiquement hérité du groupe project-x-team. L'harmonie était restaurée. Leçon : Le SGID sur un répertoire est la manière correcte et propre de gérer les dossiers de groupe partagés.

La faille de sécurité du site web public

Un développeur web freelance a lancé un simple site PHP pour un client. Pour plus de commodité, il a laissé le fichier de configuration de la base de données, config.inc.php, dans le même répertoire que la page d'accueil. Le fichier contenait le nom d'utilisateur et le mot de passe de la base de données en texte clair. Ses permissions étaient le 644 par défaut (-rw-r--r--), ce qui signifiait que l'utilisateur du serveur web pouvait le lire (bien), mais aussi n'importe qui sur la planète qui devinait l'URL. Un scanner de sécurité a trouvé le fichier, et l'attaquant a téléchargé les identifiants de la base de données. La correction aurait dû être chmod 600 config.inc.php, le rendant lisible uniquement par son propriétaire (le processus du serveur web). Leçon : Ne présumez jamais que les permissions par défaut sont sécurisées. Les fichiers sensibles comme les configurations et les clés privées doivent être verrouillés pour être aussi restrictifs que possible.

Erreurs et pièges courants

  • Le coup de massue chmod 777. Frustrés, beaucoup sont tentés de lancer chmod -R 777 . sur un répertoire. Cela donne récursivement à tout le monde la permission de lire, écrire et exécuter tout. C'est une vulnérabilité de sécurité catastrophique et l'équivalent numérique de retirer les portes de votre maison et de laisser une pancarte « Servez-vous » sur la pelouse. Ne le faites pas.
  • Oublier la permission x sur un répertoire. Vous pouvez avoir la permission r sur un fichier mais être incapable d'y accéder car vous n'avez pas la permission x sur l'un des répertoires parents dans son chemin. Vous avez besoin de la permission d'exécution sur tous les répertoires que vous souhaitez traverser.
  • Le mystère umask. Vous êtes-vous déjà demandé pourquoi les nouveaux fichiers que vous créez sont en 644 et non en 777 ? C'est votre umask qui est à l'œuvre. Un umask est un « masque » que votre shell applique, retirant des permissions aux fichiers et répertoires au moment de leur création. Un umask courant de 022 retire la permission d'écriture pour le Groupe et les Autres, transformant un 666 par défaut en 644.
  • Penser que chmod +x est pareil que chmod 755. Ce n'est pas le cas. chmod 755 mon_fichier définit les permissions de manière absolue. chmod +x mon_fichier ajoute le bit d'exécution pour toute classe d'utilisateur (propriétaire, groupe, autre) qui a déjà le bit de lecture, sans changer les autres bits. Le mode symbolique est relatif ; le mode octal est absolu.

Pourquoi ça doit être sur votre radar

Si vous touchez à une ligne de commande non-Windows, vous devez comprendre chmod. Ce n'est pas une option. Cette connaissance est cruciale lorsque vous :

  • Déployez n'importe quelle application sur un serveur Linux.
  • Écrivez des scripts (Shell, Python, Node.js) qui doivent être exécutés.
  • Travaillez avec Git, qui a ses propres idées sur les permissions de fichiers.
  • Mettez en place des partages de fichiers ou des environnements collaboratifs.
  • Renforcez la sécurité d'un serveur en restreignant l'accès aux fichiers sensibles.
  • Utilisez Docker, où les permissions de fichiers à l'intérieur du conteneur sont primordiales.

chmod est l'une des premières et des plus fondamentales commandes qui sépare l'utilisateur occasionnel d'un véritable opérateur système ou développeur. Le comprendre est un rite de passage pour contrôler la machine, pas seulement l'utiliser.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: Calculatrice Chmod