Linux sans magie #10 — umask : pourquoi un nouveau fichier n’a pas toujours les droits que vous imaginiez

Après plusieurs articles consacrés aux permissions, nous savons maintenant lire rwx, identifier propriétaire et groupe, utiliser chmod et diagnostiquer un Permission denied.

Mais une question reste ouverte : qui choisit les permissions d’un fichier ou d’un répertoire au moment où il est créé ?

Vous avez peut-être déjà lancé :

touch test.txt

puis obtenu avec ls -l quelque chose comme -rw-r--r--, alors que vous n’avez jamais demandé explicitement 644.

Ce comportement n’est pas magique. Une partie essentielle de l’explication tient dans une petite commande : umask.

Objectif

Dans ce lab, nous allons apprendre à afficher le umask courant, comprendre des valeurs classiques comme 022, 027 ou 077, observer leur effet sur de nouveaux fichiers et répertoires, puis restaurer proprement l’environnement de départ.

L’objectif n’est pas de mémoriser une formule. Il est de comprendre le mécanisme : une application demande certaines permissions lors de la création, puis le umask en masque une partie.

Aucun sudo n’est nécessaire.

Lab — observer avant de modifier

Placez-vous dans votre répertoire personnel puis créez un espace de travail dédié :

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

Affichez votre masque courant :

umask

Vous pourriez voir par exemple :

ou :

La valeur exacte dépend de votre environnement. Ne la modifiez pas encore.

Sauvegardons-la pour pouvoir la restaurer à la fin du lab :

original_umask=$(umask)
printf '%s\n' "$original_umask"

La deuxième commande doit afficher la même valeur que umask.

Créer un premier fichier et un premier répertoire

Créons deux objets :

touch fichier1.txt
mkdir repertoire1

Observons leurs permissions :

ls -ld fichier1.txt repertoire1

Avec un umask courant de 022, vous pourriez obtenir quelque chose proche de :

-rw-r--r-- ... fichier1.txt
drwxr-xr-x ... repertoire1

Le fichier n’est pas exécutable, alors que le répertoire possède bien des droits x.

Pourquoi cette différence alors que le même umask est actif dans les deux cas ?

Ce que fait réellement `umask`

Le mot umask désigne le file mode creation mask, autrement dit le masque de création des permissions.

Lorsqu’un programme crée un objet, il demande un certain mode. Le système retire ensuite de ce mode les bits présents dans le masque. Le umask ne fixe donc pas directement une permission finale comme 644 ou 755.

Il agit plutôt comme une règle : parmi les permissions demandées, certaines ne doivent pas être accordées.

C’est une distinction importante, car elle explique pourquoi deux types d’objets créés sous le même umask peuvent finir avec des permissions différentes.

Comprendre `022`

Reprenons un masque classique : 022.

Les trois derniers chiffres correspondent aux catégories que nous connaissons déjà : propriétaire, groupe et autres.

Catégorie	Valeur du masque	Ce qui est masqué
propriétaire	`0`	rien
groupe	`2`	écriture
autres	`2`	écriture

Dans le système octal des permissions, 4 correspond à lecture, 2 à écriture et 1 à exécution.

Avec 022, l’écriture est donc retirée pour le groupe et pour les autres lorsque le programme la demande.

Pourquoi un fichier donne souvent `644`

Lorsqu’un fichier ordinaire est créé de manière classique, l’application demande généralement un mode qui autorise au maximum lecture et écriture, sans bit d’exécution : 0666, soit rw-rw-rw-.

Avec un masque 022, les deux droits d’écriture du groupe et des autres sont retirés. On obtient alors :

rw-r--r--

soit 0644.

C’est pourquoi un touch fichier.txt sous umask 022 produit souvent un fichier en 644.

Le mot important est souvent. Le programme qui crée le fichier peut demander un mode plus restrictif dès le départ. Le umask n’ajoute jamais un droit qu’une application n’a pas demandé.

Pourquoi un répertoire donne souvent `755`

Pour un répertoire, les droits demandés sont généralement différents. Un répertoire nouvellement créé a besoin de permissions d’exécution pour pouvoir être traversé. Un appel classique à la création demande donc 0777, soit rwxrwxrwx.

Avec le même masque 022, l’écriture disparaît pour groupe et autres :

rwxr-xr-x

soit 0755.

Avec un même umask 022, nous pouvons donc observer typiquement :

Objet	Mode demandé classique	Résultat courant
fichier	`0666`	`0644`
répertoire	`0777`	`0755`

Ce n’est pas une incohérence. Le mode demandé initialement n’était simplement pas le même.

Pourquoi « 777 - umask » est une mauvaise règle générale

On rencontre parfois cette astuce mentale : 777 - 022 = 755.

Elle semble fonctionner pour notre répertoire. Mais si on l’applique mécaniquement à un fichier, elle ferait croire que le fichier devrait aussi finir en 755, donc devenir exécutable. Ce n’est pas le comportement classique de touch.

La bonne logique est donc : mode demandé par le programme → application du masque → permissions finales.

Pour un débutant, il n’est pas nécessaire de calculer chaque bit à la main. Retenez surtout que le umask retire des permissions parmi celles qui étaient demandées.

Modifier temporairement le masque

Essayons maintenant un masque plus restrictif :

umask 027
umask

Vous devriez obtenir une valeur équivalente à :

Avec 027, l’écriture est masquée pour le groupe, et tous les droits classiques sont masqués pour les autres.

Créons de nouveaux objets :

touch fichier2.txt
mkdir repertoire2
ls -ld fichier2.txt repertoire2

Dans un environnement classique, vous devriez observer quelque chose proche de :

-rw-r----- ... fichier2.txt
drwxr-x--- ... repertoire2

soit 640 pour le fichier et 750 pour le répertoire.

Comparons avec les objets créés avant le changement :

ls -ld fichier1.txt fichier2.txt repertoire1 repertoire2

Vous constaterez que fichier1.txt et repertoire1 n’ont pas changé.

C’est essentiel : modifier le umask n’altère pas les objets existants. Il agit au moment de la création. Pour modifier des permissions déjà en place, on utilise notamment chmod.

`umask` et `chmod` ne font pas le même travail

La distinction peut maintenant se résumer simplement.

umask répond à la question : quelles permissions faut-il empêcher d’être accordées automatiquement à un nouvel objet ?

chmod répond à une autre question : quelles permissions voulons-nous appliquer à un objet qui existe déjà ?

Cette différence évite de confondre politique de création et correction après coup.

Afficher le masque symboliquement

Avec un shell compatible POSIX comme Bash, vous pouvez demander une représentation symbolique :

umask -S

Avec umask 027, l’affichage indiquera l’équivalent des droits conservés pour le propriétaire, le groupe et les autres.

Cette vue est pratique lorsque les valeurs octales vous paraissent encore abstraites.

Petit défi — prédire `077`

Essayez maintenant de prévoir le résultat avant de lancer les commandes suivantes.

Nous définissons :

umask 077

Puis nous créons :

touch prive.txt
mkdir prive

077 masque tous les droits classiques pour le groupe et pour les autres.

Vérifiez :

ls -ld prive.txt prive

Vous devriez typiquement obtenir :

-rw------- ... prive.txt
drwx------ ... prive

soit 600 et 700.

Ce résultat est utile à comprendre, mais évitez d’en conclure qu’un umask 077 est automatiquement le bon choix partout. Sur un serveur collaboratif ou dans un environnement où plusieurs membres d’un groupe doivent partager des fichiers, un masque trop restrictif peut gêner le fonctionnement normal.

Une subtilité à connaître : ACL par défaut

Les permissions classiques et le umask ne sont pas toujours les seuls mécanismes en jeu.

Un répertoire peut posséder une ACL par défaut. Lorsqu’elle existe, elle peut participer à la détermination des permissions des nouveaux objets créés dans ce répertoire. Dans ce cas, raisonner uniquement à partir du umask classique peut être insuffisant.

Ce sujet mérite un article dédié. Pour l’instant, retenez simplement cette piste : si un résultat de création ne correspond pas à ce que votre umask laisse prévoir, des ACL par défaut peuvent expliquer la différence.

Bonnes pratiques

Commencez toujours par observer avant de modifier :

umask
umask -S

Si vous testez une valeur différente, faites-le dans un lab et dans le shell courant, puis créez de nouveaux objets pour comparer les résultats.

Évitez de changer définitivement votre umask dans des fichiers de configuration tant que vous n’avez pas identifié les besoins réels de votre environnement : poste personnel, serveur multi-utilisateurs, travail collaboratif, service applicatif ou politique de sécurité.

Sécurité

Le umask participe au principe du moindre privilège : mieux vaut éviter d’accorder automatiquement des droits inutiles à la création plutôt que devoir corriger systématiquement des objets trop permissifs après coup.

Mais « plus restrictif » ne signifie pas toujours « meilleur ». Une politique de permissions doit rester compatible avec l’usage attendu, notamment pour les groupes de travail et les applications qui partagent des fichiers.

Coûts

Aucun coût matériel ou logiciel n’est associé à ce lab.

Limites et points de vigilance

Le résultat final dépend du mode demandé par l’application, pas seulement du umask.

Le umask d’un shell est hérité par les processus lancés depuis ce shell, mais changer le umask d’un shell ne modifie pas rétroactivement les permissions d’objets existants.

Enfin, des ACL par défaut ou d’autres mécanismes de contrôle d’accès peuvent compléter ce modèle simple.

Nettoyage / rollback

Nous avons sauvegardé la valeur initiale dans original_umask.

Restaurons-la :

umask "$original_umask"
umask

La valeur affichée doit correspondre à celle observée au début du lab.

Revenez ensuite dans votre répertoire personnel et supprimez uniquement le répertoire de test :

cd
pwd
rm -r linux-sans-magie-lab

Ce qu’il faut retenir

umask n’est pas un autre nom de chmod.

chmod modifie les permissions d’un objet existant. umask intervient lors de la création de nouveaux objets en masquant certains bits du mode demandé par le programme.

La méthode à retenir est donc :

programme demande des permissions → umask masque certains droits → l’objet est créé → ls -l permet de vérifier.

À partir de là, 022, 027 ou 077 cessent d’être des nombres mystérieux. Ils deviennent une manière de répondre à une question simple : quels droits ne voulons-nous pas accorder automatiquement ?

Références officielles

umask(2) — set file mode creation mask — Linux man-pages project
mkdir(2) — create a directory — Linux man-pages project
umask(1p) — set the file mode creation mask — POSIX manual page
Bourne Shell Builtins — umask — GNU Bash manual

Conclusion

Nous venons de compléter le premier grand bloc de la série consacré aux permissions.

Après avoir appris à lire rwx, à utiliser chmod et à diagnostiquer Permission denied, nous savons maintenant aussi expliquer pourquoi les permissions apparaissent dès la création d’un fichier ou d’un répertoire.

La prochaine étape logique de Linux sans magie sera de quitter progressivement les fichiers pour regarder ce qui tourne réellement sur la machine : les processus.