Chapitre 3.3 — Permissions Unix (rwx)

⏱️ TL;DR — Chaque fichier Linux porte des permissions qui disent qui peut le lire (r), l’écrire (w) et l’exécuter (x). Ces trois droits s’appliquent à trois classes : le propriétaire (u), le groupe (g) et tous les autres (o). D’où la notation qu’on lit dans ls -l : -rw-r--r--. On règle ces droits avec chmod, en octal (chmod 644 fichier, où chaque chiffre encode r=4 w=2 x=1) ou en symbolique (chmod u+x script.sh). On change le propriétaire avec chown user:group. Les nouveaux fichiers reçoivent des droits par défaut fixés par le umask. En prod, quelques réflexes sauvent : clés privées en 600, dossiers web en 755, fichiers en 644 — et jamais 777, qui ouvre tout à tout le monde.

🎯 Objectifs

• Lire une ligne de ls -l et décoder -rw-r--r-- / drwxr-xr-x.
• Comprendre le modèle 3 classes × 3 droits et la conversion octal ↔ rwx.
• Régler les permissions avec chmod (octal et symbolique) et la propriété avec chown.
• Savoir pourquoi un script a besoin du bit exécutable et ce que fait le umask.
• Appliquer les bons droits en prod (clés en 600, dossiers 755, fichiers 644) et fuir le 777.

Le modèle : 3 droits, 3 classes

Le système de permissions d’Unix est d’une simplicité redoutable. Trois droits possibles sur un fichier :

• r (read, lire) : lire le contenu du fichier — ou, pour un dossier, lister ce qu’il contient.
• w (write, écrire) : modifier le fichier — ou, pour un dossier, créer/supprimer/renommer des fichiers dedans.
• x (execute, exécuter) : lancer le fichier comme un programme — ou, pour un dossier, entrer dedans (le « traverser » avec cd).

Et trois classes de personnes à qui ces droits s’appliquent :

• u (user) : le propriétaire du fichier.
• g (group) : les membres du groupe propriétaire.
• o (others) : tous les autres (le reste du monde).

Chaque fichier a donc 9 bits de permissions : rwx pour u, rwx pour g, rwx pour o. C’est tout. Comprendre ces neuf cases, c’est comprendre 90 % de la sécurité des fichiers sous Linux.

💡 Réflexe — Pour un dossier, le x ne veut pas dire « exécuter » mais « traverser ». Un dossier lisible (r) mais non traversable (x absent) est presque inutile : tu peux voir la liste des noms mais pas entrer ni accéder aux fichiers. C’est pour ça que les dossiers ont besoin de x là où les fichiers non exécutables n’en ont pas — d’où le classique 755 pour les dossiers et 644 pour les fichiers.

Lire un ls -l

La commande ls -l affiche les permissions en tête de chaque ligne, sous forme de dix caractères :

ls -l
# -rw-r--r-- 1 deploy deploy  1240 ... .env
# drwxr-xr-x 4 deploy www-data 4096 ... public

Décortiquons -rw-r--r-- :

-  rw-  r--  r--
│   │    │    └── others : r--   -> lecture seule
│   │    └─────── group  : r--   -> lecture seule
│   └──────────── user   : rw-   -> lecture + écriture
└──────────────── type   : "-" = fichier ordinaire ("d" = dossier, "l" = lien symbolique)

Le premier caractère n’est pas une permission : c’est le type (- fichier, d dossier, l lien). Les neuf suivants se lisent par groupes de trois : d’abord le propriétaire, puis le groupe, puis les autres. Ainsi -rw-r--r-- veut dire : « fichier ; le propriétaire peut lire et écrire ; le groupe et les autres peuvent seulement lire ». Et drwxr-xr-x : « dossier ; propriétaire rwx (tout) ; groupe et autres r-x (lister + traverser, pas écrire) ».

🐚 Au terminal — Deux vues utiles :

ls -l          # permissions détaillées, propriétaire et groupe
ls -la         # idem + les fichiers cachés (ceux commençant par un point, ex. .env, .ssh)
stat monfichier   # tout le détail : droits en rwx ET en octal, propriétaire, dates

Octal : les permissions en chiffres

La notation rwx a un équivalent numérique très pratique, où chaque droit vaut une puissance de deux :

• r = 4, w = 2, x = 1.

On additionne pour une classe, ce qui donne un chiffre de 0 à 7. On met bout à bout les trois classes (u, g, o) : un nombre à trois chiffres. Ainsi rwx = 4+2+1 = 7, rw- = 4+2 = 6, r-x = 4+1 = 5, r-- = 4.

Donc les combinaisons qu’on croise sans arrêt :

chmod : changer les permissions

chmod (change mode) règle les droits. Deux syntaxes, les deux valent la peine de les connaître.

En octal — tu poses les droits absolus, d’un coup :

chmod 644 index.html    # rw-r--r-- : proprio lit/écrit, le reste lit
chmod 755 deploy.sh     # rwxr-xr-x : rend le script exécutable par tous
chmod 600 ~/.ssh/id_ed25519   # rw------- : clé privée, proprio SEUL
chmod 640 .env          # rw-r----- : proprio écrit, groupe lit, autres rien

En symbolique — tu ajoutes (+), retires (-) ou fixes (=) un droit, sans toucher au reste. Pratique pour un ajustement ciblé :

chmod u+x deploy.sh     # ajoute le droit d'exécution au PROPRIÉTAIRE
chmod go-w fichier      # retire l'écriture au GROUPE et aux AUTRES (go = group+others)
chmod a+r fichier       # ajoute la lecture à TOUS (a = all = u+g+o)
chmod -R 755 public/    # -R = récursif : applique à tout le contenu du dossier

⚠️ Piège — chmod -R (récursif) applique le même mode à tout, fichiers et dossiers confondus. Or les dossiers ont besoin de x (pour être traversés) que les fichiers n’ont pas. Un chmod -R 644 sur une arborescence rend les dossiers intraversables (plus de x) et casse l’accès ; un chmod -R 755 rend au contraire tous les fichiers exécutables, ce qui est inutile et suspect. La bonne méthode : traiter dossiers et fichiers séparément (par exemple avec find … -type d en 755 et find … -type f en 644).

chown et chgrp : changer le propriétaire

chmod règle quels droits. chown (change owner) règle à qui appartient le fichier — propriétaire et/ou groupe :

sudo chown deploy fichier              # change le PROPRIÉTAIRE -> deploy
sudo chown deploy:www-data fichier     # change proprio -> deploy ET groupe -> www-data
sudo chown -R deploy:www-data /var/www/formacampus   # récursif sur toute l'arbo
sudo chgrp www-data fichier            # change SEULEMENT le groupe

Changer le propriétaire d’un fichier requiert en général les droits root (sinon on pourrait « donner » ses fichiers à n’importe qui pour contourner les quotas ou brouiller les pistes) — d’où le sudo.

🧭 Sur FormaCampus — Le dossier de l’app est monté en deploy:www-data. Le compte deploy possède les fichiers (il déploie, il écrit), et le groupe www-data (celui de Nginx) peut les lire pour les servir. Concrètement : sudo chown -R deploy:www-data /var/www/formacampus, puis les dossiers en 755 et les fichiers en 644 — Nginx lit tout, mais ne peut rien modifier. Les fichiers de secrets (.env de l’API Symfony) sont eux en 640, propriété deploy:formacampus, pour que seuls le déployeur et le service applicatif y accèdent, jamais le reste du monde.

Le bit exécutable et les scripts

Sous Linux, un fichier n’est pas exécutable parce qu’il finit par .sh — l’extension ne compte pas. Il est exécutable parce qu’il porte le bit x. Un script fraîchement écrit est un simple fichier texte (644) : pour le lancer directement, il faut lui ajouter x :

./deploy.sh          # Permission denied : le bit x manque
chmod +x deploy.sh   # on ajoute le droit d'exécution
./deploy.sh          # ça marche maintenant

C’est aussi ce bit x qui, combiné à la première ligne du script (le shebang #!/bin/bash), permet au système de savoir avec quel interpréteur l’exécuter.

umask : les permissions par défaut

Quand tu crées un fichier, il ne naît pas avec des droits arbitraires : ils sont dérivés du umask, un masque qui retire des permissions à la valeur de base. La base est 666 pour les fichiers (rw- pour tous) et 777 pour les dossiers ; le umask soustrait ce qu’il faut cacher.

umask         # affiche le masque courant, ex. 0022
# Avec umask 022 : les fichiers naissent en 644, les dossiers en 755
# (022 retire le droit d'écriture au groupe et aux autres)

Le umask 022 par défaut est raisonnable pour un usage courant. Pour des données sensibles, un umask 077 fait naître les fichiers en 600 (privés au propriétaire) — utile pour un compte qui manipule des secrets. On le comprend, on le laisse en général tel quel, et on ajuste explicitement au cas par cas avec chmod.

📚 La doc — man chmod, man chown, man umask. Pour la mécanique complète (bits spéciaux setuid/setgid/sticky bit, non couverts ici car rarement utiles à ce stade), le man et la doc de ta distribution font autorité. Reste sur les cas courants tant que tu n’as pas un besoin précis.

Les bons réflexes en prod (et le danger du 777)

Quelques valeurs à connaître par cœur pour un serveur web :

• Clés privées SSH / TLS → 600 (rw-------). Personne d’autre que le propriétaire ne doit pouvoir les lire. SSH refuse même de les utiliser si elles sont trop permissives.
• Fichiers de secrets (.env, mots de passe DB) → 600 ou 640 selon qu’un groupe doit lire.
• Dossiers d’un site web → 755 (traversables et lisibles, non modifiables par les autres).
• Fichiers d’un site web (HTML, CSS, images) → 644 (lisibles par le serveur, modifiables par le seul proprio).
• Scripts à exécuter → 755 (ou 750 si le groupe suffit).

⚠️ Piège — chmod 777 : le réflexe désastreux du débutant qui « veut juste que ça marche ». 777 = rwxrwxrwx = tout le monde peut tout faire, y compris écrire et exécuter. Sur un serveur exposé, c’est une porte ouverte : n’importe quel processus (donc un attaquant qui a pris pied sur la machine) peut modifier ton code, y déposer un script malveillant et le lancer. Un « permission denied » ne se règle jamais par 777 — il se règle en trouvant le bon propriétaire et le bon droit minimal (souvent un chown vers le bon user, ou un 644/755). Si tu vois 777 quelque part, considère-le comme un bug de sécurité à corriger.

🔒 Sécurité — Le principe de moindre privilège s’applique aux fichiers comme aux comptes : chaque fichier ne doit être accessible qu’à ceux qui en ont besoin, et seulement pour ce qui est nécessaire (lecture seule si l’écriture n’est pas requise). Un secret lisible par « others » est un secret compromis dès qu’un autre compte de la machine est ouvert. Vérifie systématiquement les droits de tes .env et de tes clés avec ls -l.

✏️ Exercices

Exercice 1 — Décode et convertis. Traduis ces permissions dans l’autre notation, et dis en une phrase ce qu’elles autorisent : (a) rw-r----- en octal ; (b) 750 en rwx.

Exercice 2 — Répare une clé et un dossier web. Deux problèmes : (1) ssh refuse ta clé privée avec un avertissement « permissions too open » ; ls -l montre -rw-r--r-- id_ed25519. (2) Le dossier /var/www/formacampus appartient à root:root et Nginx (qui tourne en www-data) renvoie des erreurs de permission. Donne les commandes.

chmod 600 ~/.ssh/id_ed25519   # rw------- : proprio seul

sudo chown -R deploy:www-data /var/www/formacampus
sudo find /var/www/formacampus -type d -exec chmod 755 {} \;   # dossiers traversables
sudo find /var/www/formacampus -type f -exec chmod 644 {} \;   # fichiers lisibles

🧠 Quiz de révision

Chapitre suivant : Processus & signaux — voir ce qui tourne, le suivre, et l’arrêter proprement.