03 - Permissions et droits d'acces

Ce que tu vas apprendre

• Le système rwx (read, write, exécuté) et comment le lire
• chmod en numérique (755) et en symbolique (u+x)
• chown, chgrp et umask
• Les bits speciaux (SUID, SGID, sticky bit)
• Debugger un "permission denied" sans paniquer

Prerequisites

Savoir manipuler des fichiers. Voir l'article sur les fichiers.

Le "permission denied" qui ruine ta journee

Chaque dev a vecu ca : tu deploies, tu lances ton script, et bam : Permission denied. Tu fais sudo devant, ca marche, et tu passes a autre chose. Sauf que tu viens de masquer un vrai problème. Comprendre les permissions, c'est comprendre pourquoi ca casse et comment le réparer proprement.

Lire les permissions

Quand tu fais ls -la, la première colonne ressemble a des hieroglyphes :

bash$ ls -la
drwxr-xr-x  5 nicolas dev  4096 Mar 29 10:00 src
-rw-r--r--  1 nicolas dev  1247 Mar 29 09:15 package.json
-rwxr-xr-x  1 nicolas dev   892 Mar 29 08:00 deploy.sh
lrwxrwxrwx  1 nicolas dev    15 Mar 28 14:00 config -> /etc/myapp.conf

Decomposons -rwxr-xr-x :

-   rwx   r-x   r-x
|    |     |     |
|    |     |     +-- Autres (others) : r-x = lire + executer
|    |     +-------- Groupe (group) : r-x = lire + executer
|    +-------------- Proprietaire (owner) : rwx = lire + ecrire + executer
+------------------- Type : - = fichier, d = dossier, l = lien

Chaque position a trois lettres possibles :

• r (read) : lire le contenu
• w (write) : modifier le contenu
• x (exécuté) : exécuter (fichier) ou acceder (dossier)
• - : pas de permission

Le piège des permissions sur les dossiers

Pour les fichiers, c'est intuitif. Pour les dossiers, c'est différent :

Le piège classique : un dossier avec r-- mais sans x. Tu peux voir les noms des fichiers avec ls, mais tu ne peux pas les ouvrir ni entrer dans le dossier. C'est contre-intuitif mais logique : x sur un dossier signifie "traverser".

bash# Demonstration
$ mkdir test && chmod 444 test
$ ls test
# ls: cannot access 'test/file.txt': Permission denied
# (on voit les noms mais pas les details)
$ cd test
# bash: cd: test: Permission denied

chmod : changer les permissions

Deux syntaxes. La numérique est la plus courante :

Syntaxe numérique (octale)

Chaque permission a une valeur : r=4, w=2, x=1. Tu additionnes :

rwx = 4+2+1 = 7
rw- = 4+2+0 = 6
r-x = 4+0+1 = 5
r-- = 4+0+0 = 4
--- = 0+0+0 = 0

Tu donnes trois chiffres : owner, group, others.

bashchmod 755 deploy.sh    # rwxr-xr-x (scripts executables)
chmod 644 config.json  # rw-r--r-- (fichiers de config)
chmod 600 .env         # rw------- (fichiers secrets)
chmod 700 .ssh/        # rwx------ (dossier SSH)
chmod 777 temp/        # rwxrwxrwx (JAMAIS en prod)

Les combinaisons a retenir :

• 755 : executables et dossiers standards
• 644 : fichiers standards
• 600 : fichiers sensibles (.env, clés privees)
• 700 : dossiers sensibles (.ssh)

Syntaxe symbolique

Plus lisible pour des modifications ponctuelles :

bashchmod u+x script.sh         # Ajouter execute pour le proprietaire
chmod g-w fichier.txt        # Retirer ecriture pour le groupe
chmod o-rwx secret.key       # Retirer tout pour les autres
chmod a+r readme.txt         # Ajouter lecture pour tous (a = all)
chmod u=rwx,g=rx,o=rx file   # Definir explicitement (equivalent de 755)

# Recursif
chmod -R 755 dossier/        # Appliquer recursivement

chown et chgrp : changer le proprietaire

bash# Changer le proprietaire
chown nicolas fichier.txt
chown nicolas:dev fichier.txt         # Proprietaire ET groupe
chown -R www-data:www-data /var/www/  # Recursif

# Changer le groupe seulement
chgrp dev fichier.txt
chgrp -R docker /opt/containers/

Un cas frequent : apres un docker cp ou un git clone en root, les fichiers appartiennent a root. Tu dois faire un chown -R pour récupérer la propriété :

bash$ ls -la
-rw-r--r-- 1 root root 1247 Mar 29 10:00 package.json
# Oops, c'est root qui possede le fichier

$ sudo chown -R nicolas:nicolas .
$ ls -la
-rw-r--r-- 1 nicolas nicolas 1247 Mar 29 10:00 package.json

umask : les permissions par défaut

Le umask definit les permissions retirees lors de la création d'un fichier :

bash$ umask
0022

# Ca signifie :
# Fichiers crees : 666 - 022 = 644 (rw-r--r--)
# Dossiers crees : 777 - 022 = 755 (rwxr-xr-x)

# Changer le umask (pour la session)
umask 077    # Fichiers: 600, Dossiers: 700 (restrictif)
umask 002    # Fichiers: 664, Dossiers: 775 (collaboratif)

Les bits speciaux : SUID, SGID, sticky bit

Tu ne les utiliseras pas souvent, mais tu dois savoir qu'ils existent :

bash# SUID (Set User ID) - le fichier s'execute avec les droits du proprietaire
chmod u+s /usr/bin/passwd
# C'est pour ca que passwd peut modifier /etc/shadow meme sans sudo
$ ls -la /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Mar 14 2024 /usr/bin/passwd
#    ^ le 's' a la place du 'x'

# SGID (Set Group ID) - les fichiers crees heritent du groupe du dossier
chmod g+s /opt/projet/
# Utile pour les dossiers partages

# Sticky bit - seul le proprietaire peut supprimer ses fichiers
chmod +t /tmp/
$ ls -ld /tmp
drwxrwxrwt 15 root root 4096 Mar 29 10:00 /tmp
#                     ^ le 't' a la fin
# C'est pour ca que tu ne peux pas supprimer les fichiers des autres dans /tmp

Debugger "permission denied"

Quand tu as un "permission denied", voici la checklist :

bash# 1. Verifier les permissions du fichier
ls -la fichier_probleme

# 2. Verifier qui tu es
whoami
id
# uid=1000(nicolas) gid=1000(nicolas) groups=1000(nicolas),27(sudo),998(docker)

# 3. Verifier les permissions de chaque dossier parent
# (il faut x sur chaque dossier du chemin)
namei -l /chemin/complet/vers/fichier

# 4. Pour un script : verifier qu'il est executable
file script.sh
# script.sh: Bash script, ASCII text executable
chmod +x script.sh

# 5. Pour une application web : verifier le proprietaire
ls -la /var/www/html/
# Les fichiers doivent appartenir a www-data (ou l'utilisateur du serveur web)

Le cas le plus sournois : tu as les permissions sur le fichier, mais pas le x sur un dossier parent. namei -l te montre les permissions de chaque étape du chemin. C'est l'outil que j'aurais aime connaître plus tot.

Pour des cas concrets de debugging de permissions dans un contexte Docker ou CI/CD, paltemps.fr propose des guides pratiques.

Résumé

• rwx = lire/écrire/exécuter, applique a owner/group/others
• chmod 755 pour les executables, chmod 644 pour les fichiers, chmod 600 pour les secrets
• chown -R user:group apres un clone ou un copy en root
• Sur un dossier, x signifie "peut traverser", pas "peut exécuter"
• namei -l pour debugger les permission denied sur un chemin complet

Precedent : Fichiers et répertoires | Suivant : Utilisateurs et groupes

Sources

• chmod man page
• Linux File Permissions Explained - Red Hat
• Understanding Linux Permissions - DigitalOcean