Permissions Linux : chmod, chown et umask enfin clairs

ls -l script.sh
-rwxr-xr-- 1 alice devs 4096 Jul  1 10:00 script.sh

Décompose -rwxr-xr-- en 1 + 3 + 3 + 3 caractères :

• - : le type — - fichier, d dossier, l lien symbolique.
• rwx : le propriétaire (alice) peut lire, écrire, exécuter.
• r-x : le groupe (devs) peut lire et exécuter, pas écrire.
• r-- : les autres peuvent seulement lire.

Trois blocs, toujours dans le même ordre : user, group, others. r = read, w = write, x = execute (pour un dossier, x = le droit d'y entrer).

Chaque droit vaut un nombre : r = 4, w = 2, x = 1. Tu additionnes par bloc : rwx = 7, r-x = 5, r-- = 4. D'où les classiques :

• 755 (rwxr-xr-x) : scripts et dossiers — le propriétaire fait tout, les autres lisent et traversent.
• 644 (rw-r--r--) : fichiers normaux — le propriétaire édite, les autres lisent.
• 600 (rw-------) : secrets (clés SSH, .env) — personne d'autre que toi.

chmod 644 notes.txt        # octal : fixe tout d'un coup / octal: set everything at once
chmod u+x deploy.sh        # symbolique : ajoute x au propriétaire / symbolic: add x for the owner
chmod g-w,o-r config.yml   # retire w au groupe, r aux autres / remove w from group, r from others
chmod -R 755 /var/www/site # récursif sur un dossier / recursive on a directory

Deux syntaxes, même résultat. L'octale (chmod 644) remplace toutes les permissions d'un coup — idéale quand tu sais l'état final voulu. La symbolique (u+x, g-w) modifie seulement ce que tu cites : u/g/o/a pour user/group/others/all, +/-/= pour ajouter/retirer/fixer.

sudo chown alice fichier.txt        # change le propriétaire / change the owner
sudo chown alice:devs fichier.txt   # propriétaire ET groupe / owner AND group
sudo chgrp devs fichier.txt         # groupe seulement / group only
sudo chown -R alice:devs /srv/app   # récursif / recursive

chmod règle quels droits ; chown règle à qui ils s'appliquent. Changer le propriétaire demande sudo (tu ne peux pas « donner » un fichier). La forme user:group fait les deux en une commande.

Ton conteneur crashe avec Permission denied sur son volume monté ? C'est presque toujours un conflit d'UID : Linux ne compare pas des noms d'utilisateurs mais des numéros. Si le process du conteneur tourne avec l'UID 1000 mais que le dossier hôte appartient à root (UID 0), le conteneur ne peut pas écrire — peu importe les noms.

La solution : donner le dossier hôte à l'UID que le conteneur utilise (indiqué dans la doc de l'image, ou visible avec docker exec <ctn> id).

docker exec mon-conteneur id       # → uid=1000 gid=1000
sudo chown -R 1000:1000 ./app-data # aligne le dossier hôte sur l'UID du conteneur
                                   # align the host dir with the container UID

umask définit les permissions retirées par défaut à chaque fichier créé : avec le umask courant 022, un fichier naît en 644 (666 − 022) et un dossier en 755 (777 − 022). C'est pour ça que tes nouveaux fichiers ne sont jamais exécutables ni modifiables par le groupe sans que tu le demandes.

chmod -R 777 « répare » l'erreur en donnant tous les droits à tout le monde — y compris à n'importe quel process compromis sur la machine. C'est le sparadrap qui masque le vrai problème (un mauvais propriétaire) et crée une faille durable.

À la place : identifie qui doit accéder (ls -l, id, docker exec ... id), puis corrige le propriétaire avec chown et garde des droits minimaux (755/644, 600 pour les secrets). Si plusieurs utilisateurs doivent écrire, crée un groupe commun plutôt que d'ouvrir à tous.