Retour au cours

infra / linux-bash

Permissions et propriétaires (chmod/chown)

Leçon 41 exercice

Explication

Linux a été pensé dès le départ pour être utilisé par plusieurs personnes en même temps sur la même machine, un héritage d'Unix conçu pour de gros serveurs partagés. Pour que cette cohabitation fonctionne sans que chacun puisse tout casser chez l'autre, chaque fichier appartient à un utilisateur et à un groupe, et porte des permissions précises.

Ce que vous allez apprendre

  • Lire une ligne ls -l et décoder les 10 caractères de permissions (type + rwx x3)
  • Comprendre pourquoi chmod 600 protège une clé privée SSH et pourquoi SSH la refuse sinon
  • Utiliser chmod en notation numérique (644, 755) et symbolique (u+x, g-w)
  • Distinguer le sens de "x" sur un fichier (exécuter) et sur un dossier (le traverser)
  • Régler l'umask pour fixer les permissions par défaut d'un serveur en production

Dans quel contexte ?

Un administrateur système vient de générer une nouvelle clé SSH pour se connecter à un serveur de production, mais la connexion échoue avec l'erreur "UNPROTECTED PRIVATE KEY FILE". Le problème n'est ni le réseau ni le mot de passe : le fichier ~/.ssh/id_ed25519 est lisible par d'autres utilisateurs de la machine. Comprendre chmod 600 et pourquoi SSH l'exige résout ce type d'incident en quelques secondes.

Une fois ça posé, voyons comment ces droits sont organisés

Pour chaque fichier, on définit séparément les droits du propriétaire, ceux de son groupe, et ceux de "tout le monde" (other). Trois catégories bien distinctes, et pour chaque catégorie, il n'existe que trois droits possibles : lecture, écriture, exécution.

ValeurSymboliqueSens
7rwxlecture + écriture + exécution
6rw-lecture + écriture
5r-xlecture + exécution
4r--lecture seule
0---aucun droit

C'est ce croisement entre trois catégories et trois droits qui donne les fameux nombres comme 644 ou 755 : chaque chiffre encode une combinaison de ces droits pour une catégorie d'utilisateurs (propriétaire, groupe, autres).

Prérequis

Il faut être à l'aise avec ls -l et savoir lire une ligne de résultat (nom du propriétaire, groupe, taille) — voir la leçon sur la manipulation de fichiers.

Un point qui déroute presque tout le monde au début

Pour un fichier, le droit "x" veut dire "peut être exécuté", ce qui est assez intuitif. Mais pour un dossier, ce même "x" ne veut pas dire "lancer" : il signifie "pouvoir y entrer", c'est-à-dire le traverser.

Un dossier lisible mais non exécutable (chmod 644 sur un dossier) permet donc de lister son contenu avec ls, mais pas d'accéder aux fichiers qu'il contient avec cat ou cd. C'est une nuance essentielle : elle explique la majorité des erreurs "Permission denied" mystérieuses que tu rencontreras un jour.

Bonne pratique

Toujours chmod 600 id_rsa (ou id_ed25519) sur une clé privée SSH juste après sa création, avant même de l'utiliser. Sans ça, la plupart des clients SSH refusent purement et simplement de s'en servir, par mesure de sécurité contre un vol de clé sur une machine partagée.

Pour aller plus loin : l'umask

Il reste une question à régler : quelles permissions reçoit un fichier tout juste créé, avant même qu'on lui applique chmod ? La réponse est l'umask, un masque soustrait des droits maximum (666 pour un fichier, 777 pour un dossier), appliqué automatiquement à chaque création.

Cela permet de définir, une fois pour toutes, un niveau de sécurité par défaut sans avoir à penser à chmod après chaque création de fichier. Une valeur comme umask 0027 fait que tout nouveau fichier créé sur le serveur aura par défaut les permissions 640 (pas d'accès du tout pour "other"), un réglage particulièrement important à durcir sur un serveur en production.

Le piège à connaître

Confondre chmod -R 755 appliqué sans réfléchir sur un dossier entier — ce qui rend TOUS les fichiers exécutables, y compris de simples fichiers de configuration qui n'ont aucune raison de l'être — est une erreur fréquente. Mieux vaut cibler précisément dossiers (755) et fichiers (644) séparément avec find.

Maintenant que tu sais qui a le droit de faire quoi sur un fichier, la suite logique est de regarder ce qui se passe quand ces fichiers deviennent des programmes en cours d'exécution : direction la leçon sur les processus.

Commandes & code

Permissions et propriétaires

bash
ls -l fichier.txt
# -rw-r--r-- 1 ned  devs  1240 sep  3 10:00 fichier.txt
#  |||||||||   |     |
#  |||||||||   |     └── groupe propriétaire
#  |||||||||   └──────── utilisateur propriétaire
#  └└└└└└└└└──────────── type + permissions (user/group/other)

# Décomposition des 10 caractères : [type][rwx user][rwx group][rwx other]
# type : - fichier, d dossier, l lien symbolique
# r=4 (lecture) w=2 (écriture) x=1 (exécution / traverser un dossier)

chmod 644 fichier.txt      # rw-r--r--  : propriétaire lit/écrit, reste lit seulement
chmod 755 script.sh         # rwxr-xr-x : propriétaire full, reste lit + exécute
chmod 600 id_rsa              # rw-------  : privé, typique d'une clé SSH
chmod 700 dossier_prive/       # rwx------  : seul le propriétaire peut y entrer

# Notation symbolique (utile pour modifier sans tout recalculer)
chmod u+x script.sh          # ajoute exécution pour le propriétaire (user)
chmod g-w fichier.txt          # retire l'écriture pour le groupe
chmod o=r fichier.txt            # fixe "other" exactement à lecture seule
chmod a+r fichier.txt              # ajoute lecture pour tout le monde (all)
chmod -R 755 dossier/                # récursif sur toute l'arborescence

# Propriétaire et groupe
chown ned fichier.txt                 # change le propriétaire
chown ned:devs fichier.txt              # change propriétaire ET groupe
chown -R www-data:www-data /var/www/      # récursif, typique pour un serveur web
chgrp devs fichier.txt                     # change uniquement le groupe

# Permissions spéciales
chmod u+s /usr/bin/passwd     # setuid : exécute avec les droits du propriétaire (root)
chmod g+s /var/www/shared/      # setgid sur un dossier : les nouveaux fichiers héritent du groupe
chmod +t /tmp                    # sticky bit : seul le propriétaire d'un fichier peut le supprimer

# umask : masque appliqué par défaut à la création (soustrait des permissions max 666/777)
umask                # affiche le masque courant, ex: 0022
umask 0027             # nouveaux fichiers : 640, nouveaux dossiers : 750
ValeurSymboliqueSens
7rwxlecture + écriture + exécution
6rw-lecture + écriture
5r-xlecture + exécution
4r--lecture seule
0---aucun droit

Résumé

  • chmod gère les droits, chown/chgrp gèrent la propriété.
  • Toujours chmod 600 sur une clé privée SSH, sinon SSH refuse de l'utiliser.
  • umask définit les permissions par défaut à la création — utile à durcir en prod.

Exercices pratiques

1 disponible
1

Mission : résoudre une clé SSH refusée en production

Objectif : Diagnostiquer une erreur de permissions liée à SSH, puis durcir les permissions par défaut d'un serveur.

Contexte

Un administrateur vient de générer une clé SSH pour se connecter à un serveur de production. La connexion échoue avec l'erreur UNPROTECTED PRIVATE KEY FILE. ls -l sur la clé donne :

bash
-rw-r--r-- 1 ned devs 411 sep 3 10:00 id_ed25519
Résoudre l’exercice →