Linux sans magie #9 — Pourquoi « Permission denied » n’est pas une catastrophe

Permission denied est probablement l’un des messages les plus intimidants lorsqu’on débute sous Linux.

Pourtant, il signifie généralement quelque chose de beaucoup plus simple : Linux a compris ce que vous vouliez faire, mais les règles d’accès actuelles ne vous l’autorisent pas.

Dans cet article, nous allons apprendre à ne plus corriger ce message au hasard.

Notre méthode sera toujours la même : observer → identifier l’utilisateur → inspecter le chemin → comprendre le droit manquant → corriger uniquement ce qui est nécessaire → vérifier.

Objectif

À la fin du lab, vous saurez diagnostiquer plusieurs causes classiques de Permission denied sans dégainer automatiquement sudo ou chmod 777.

Vous utiliserez essentiellement :

whoami
id
ls -l
ls -ld

L’idée n’est pas d’apprendre une commande miracle, mais de construire un réflexe de troubleshooting.

Lab — préparer notre terrain de diagnostic

Placez-vous dans votre répertoire personnel :

cd

Créez un répertoire dédié :

mkdir linux-sans-magie-lab
cd linux-sans-magie-lab

Créons un fichier :

echo "Linux sans magie" > rapport.txt

Puis observons-le :

ls -l rapport.txt

Vous pourriez obtenir quelque chose ressemblant à :

-rw-r--r-- 1 alex alex 18 Sep 9 09:00 rapport.txt

Le nom de l’utilisateur, du groupe, la taille et l’heure seront différents sur votre machine. Ce qui nous intéresse surtout est la colonne des permissions et l’identité du propriétaire et du groupe.

Premier Permission denied

Retirons volontairement au propriétaire le droit d’écriture :

chmod u-w rapport.txt

Vérifiez :

ls -l rapport.txt

Vous pourriez maintenant voir :

-r--r--r-- 1 alex alex 18 Sep 9 09:01 rapport.txt

Essayons d’ajouter du texte :

echo "Nouvelle ligne" >> rapport.txt

Votre shell devrait refuser l’opération avec un message contenant :

Permission denied

Nous venons de provoquer notre panne de manière contrôlée.

Ne corrigez rien tout de suite

Face à cette erreur, deux réflexes fréquents seraient :

sudo ...

ou :

chmod 777 rapport.txt

Nous ne ferons ni l’un ni l’autre.

La première question est : qui suis-je ?

whoami

Puis :

id

whoami affiche l’utilisateur courant. id fournit notamment son UID, son groupe principal et ses groupes supplémentaires.

Maintenant, observons le fichier :

ls -l rapport.txt

Supposons que nous voyions :

-r--r--r-- 1 alex alex 18 Sep 9 09:01 rapport.txt

Si whoami retourne alex, nous sommes le propriétaire. Le premier bloc de permissions nous concerne donc :

r--

Nous pouvons lire le fichier, mais pas l’écrire.

Le diagnostic est presque terminé.

Corriger précisément

Nous voulons permettre au propriétaire de modifier le fichier.

La correction minimale est :

chmod u+w rapport.txt

Vérifiez :

ls -l rapport.txt

Nous retrouvons :

-rw-r--r--

Réessayez :

echo "Nouvelle ligne" >> rapport.txt
cat rapport.txt

Vous devriez voir :

Linux sans magie
Nouvelle ligne

Nous avons corrigé exactement un droit. Pas de 777, pas de changement de propriétaire, pas de privilèges supplémentaires.

Ce que Permission denied ne vous dit pas

Le message indique qu’une opération a été refusée, mais il ne vous dit pas automatiquement où se situe le problème.

Le fichier final n’est pas toujours responsable. Sous Linux, l’accès à un fichier dépend aussi des répertoires qui composent son chemin. Le droit x sur un répertoire autorise notamment sa traversée, c’est-à-dire la recherche d’entrées à l’intérieur lorsque les autres conditions d’accès sont satisfaites.

Nous allons le constater.

Deuxième panne : le fichier semble pourtant correct

Créons un répertoire :

mkdir coffre

Puis un fichier à l’intérieur :

echo "secret de lab" > coffre/secret.txt

Regardons ses permissions :

ls -l coffre/secret.txt

Le fichier devrait être lisible par son propriétaire. Testez :

cat coffre/secret.txt

Cela fonctionne.

Maintenant, retirons le droit x du répertoire pour son propriétaire :

chmod u-x coffre

Regardez le répertoire :

ls -ld coffre

Puis essayez à nouveau :

cat coffre/secret.txt

Dans un environnement Linux classique, l’accès est refusé. Pourtant, les permissions de secret.txt n’ont pas changé.

Pourquoi ?

Sur un fichier ordinaire, x signifie exécution. Sur un répertoire, x correspond notamment au droit de rechercher et de traverser ce répertoire.

Linux doit pouvoir franchir les répertoires du chemin avant d’atteindre le fichier final.

Ici, ce n’est donc pas secret.txt qui bloque : c’est coffre.

Inspectons :

ls -ld coffre
ls -l coffre/secret.txt

La correction minimale est :

chmod u+x coffre

Testez :

cat coffre/secret.txt

L’accès doit fonctionner de nouveau.

Propriétaire, groupe et autres

Les permissions seules ne suffisent pas. Il faut aussi savoir à qui elles s’appliquent.

Prenons :

-rw-r--r-- 1 alex devops 32 Sep 9 09:10 rapport.txt

Nous avons trois blocs :

rw- | r-- | r--

Ils correspondent respectivement au propriétaire, au groupe et aux autres utilisateurs.

Linux détermine donc d’abord votre relation avec le fichier, puis applique le bloc de droits correspondant.

C’est pourquoi whoami, id et ls -l forment un trio aussi utile pour diagnostiquer un refus d’accès.

Une méthode simple de diagnostic

Quand une commande renvoie Permission denied, commencez par quatre questions.

1. Qui exécute la commande ?

whoami
id

2. À qui appartient l’objet ?

ls -l fichier

Pour un répertoire :

ls -ld repertoire

3. Quels droits s’appliquent réellement à cet utilisateur ?

Relisez le bloc pertinent : propriétaire, groupe ou autres.

4. Un répertoire du chemin bloque-t-il l’accès ?

Inspectez les répertoires concernés au lieu de regarder uniquement le fichier final.

Cette démarche évite beaucoup de modifications inutiles.

Pourquoi sudo n’est pas un outil de diagnostic

sudo permet d’exécuter une commande avec des privilèges supplémentaires lorsque la configuration l’autorise.

Mais transformer chaque Permission denied en sudo ... masque souvent la vraie question : pourquoi mon utilisateur normal n’a-t-il pas accès à cette ressource ?

Dans certains cas, l’absence d’accès est parfaitement volontaire : données privées, fichiers système, fichiers appartenant à un service ou séparation entre utilisateurs.

Le but n’est donc pas toujours de supprimer le refus. Parfois, le refus est le comportement attendu.

Pourquoi chmod 777 est un mauvais réflexe

Nous avons vu dans l’article précédent que :

777 = rwxrwxrwx

Utiliser :

chmod 777 fichier

pour résoudre une erreur revient à accorder tous les droits classiques au propriétaire, au groupe et aux autres, sans déterminer lequel était réellement nécessaire.

Une correction pertinente pourrait n’être que :

chmod u+w fichier

ou :

chmod u+x script.sh

ou parfois aucune modification du tout.

Le principe du moindre privilège consiste précisément à n’accorder que ce qui est nécessaire.

Et si chmod lui-même refuse ?

chmod n’est pas un passe-partout. Le propriétaire du fichier, ou un processus disposant des privilèges nécessaires, peut modifier ses bits de mode. Si le fichier ne vous appartient pas, votre tentative de modification peut elle-même être refusée.

Dans ce cas, commencez encore par :

whoami
ls -l fichier

Puis demandez-vous pourquoi ce fichier appartient à cet utilisateur avant d’essayer de changer son propriétaire ou ses droits.

Et si ls -l semble correct ?

Les permissions classiques ne sont pas le seul mécanisme de contrôle d’accès possible sous Linux.

Des ACL peuvent ajouter des règles concernant des utilisateurs ou groupes nommés. Si l’outil est installé sur votre système, vous pouvez inspecter ces règles avec :

getfacl fichier

Nous n’allons pas apprendre les ACL dans cet article. Retenez simplement qu’elles constituent une piste lorsque les permissions classiques semblent cohérentes mais que le comportement reste inattendu.

Petit défi

Créez :

mkdir atelier
echo "test" > atelier/resultat.txt

Vérifiez :

cat atelier/resultat.txt

Puis retirez une permission au répertoire :

chmod u-x atelier

Essayez :

cat atelier/resultat.txt

Votre mission : ne touchez pas au fichier resultat.txt.

Utilisez uniquement :

whoami
ls -ld atelier
ls -l atelier/resultat.txt

et expliquez pourquoi le fichier n’est plus accessible.

Ensuite seulement, restaurez le droit nécessaire :

chmod u+x atelier

Vérifiez :

cat atelier/resultat.txt

Le contenu doit redevenir accessible.

Nettoyage / rollback

Restaurons d’abord le droit de traversée au cas où vous auriez interrompu le lab au milieu :

chmod u+x coffre atelier 2>/dev/null

Revenez ensuite dans votre répertoire personnel :

cd
pwd

Puis supprimez uniquement notre lab :

rm -r linux-sans-magie-lab

Ce qu’il faut retenir

Permission denied ne signifie pas « Linux est cassé ».

Il signifie qu’une règle d’accès empêche l’opération demandée.

Votre méthode de diagnostic peut tenir en quelques commandes :

whoami
id
ls -l fichier
ls -ld repertoire

Puis raisonnez :

utilisateur
↓
propriétaire / groupe / autres
↓
r / w / x
↓
répertoires du chemin
↓
correction minimale
↓
vérification

C’est une vraie méthode de troubleshooting Linux, et elle fonctionne bien au-delà de ce petit lab.

Références officielles

• GNU Coreutils — File permissions : https://www.gnu.org/software/coreutils/manual/html_node/File-permissions.html
• GNU Coreutils — Setting permissions : https://www.gnu.org/software/coreutils/manual/html_node/Setting-Permissions.html
• Linux man-pages — access(2) : https://man7.org/linux/man-pages/man2/access.2.html
• Linux man-pages — chmod(2) : https://man7.org/linux/man-pages/man2/chmod.2.html
• Linux man-pages — getfacl(1) : https://man7.org/linux/man-pages/man1/getfacl.1.html

Conclusion

Nous avons franchi une étape importante.

Jusqu’ici, nous apprenions surtout à lire et modifier les permissions. Maintenant, nous commençons à les utiliser pour diagnostiquer un problème.

Lorsque vous verrez :

Permission denied

la question ne sera plus : « Quelle commande dois-je copier pour que ça marche ? »

Elle deviendra : « Quelle règle vient de refuser cette opération ? »

C’est exactement le réflexe que nous voulons construire dans Linux sans magie.

---