Permissions III

Sommaire :

• Complément sur les permissions pour un répertoire
  • Les permissions 'normales'
  • Le bit setGID
  • Le bit sticky
• Permissions en majuscules ou en minuscules ?
• Les permissions attribuées lors de la création d'un fichier : le masque de permissions ou "umask"
• Autres ressources

Complément sur les permissions pour un répertoire

Les permissions 'normales'

Nous avons indiqué sommairement à la page précédente que les permissions pour un répertoire ont une interprétation un peu différente de celle des permissions pour un fichier. Précisons un peu.

• le bit de lecture (r) permet d'afficher le contenu du répertoire. Mais attention, si un utilisateur possèdait, pour un répertoire donné (disons 'doc/'), uniquement les droits 'r--', alors la seule chose que cet utilisateur pourrait faire de ce répertoire serait d'en afficher le contenu mais en outre notez bien que seuls les fichiers et sous-répertoires qui sont 'à la racine' du répertoire 'doc/' seraient affichés, l'utilisateur ne pourrait en aucun cas afficher le contenu des sous-répertoires de 'doc/', faute de posséder le bit 'x' pour 'doc/', qui seul lui permettrait de 'pénétrer' dans les entrailles de 'doc/'. Autant dire que la configuration 'r--' pour un répertoire est d'un emploi plutôt rare...

• le bit d'exécution (x) pour un répertoire donne le droit d'y pénétrer, de le 'traverser' et d'en faire son répertoire de travail. Notez que si pour un répertoire donné (disons encore une fois 'doc/') vous possédez uniquement les droits '--x', alors vous êtes dans une situation un peu étrange. Vous pouvez exécuter ou modifier les fichiers de 'doc/' mais vous ne pouvez pas afficher le contenu de 'doc/' faute du bit 'r'… vous travaillez donc 'à l'aveuglette'. Naturellement ce n'est pas absolument impossible (on vous a peut-être dit que dans 'doc/' tel ou tel fichier pouvait être exécuté ou modifié tout en souhaitant que le contenu de l'ensemble du répertoire reste confidentiel) mais là encore c'est une situation pour le moins rare...

• le bit d'écriture (w) pour un répertoire est indispensable pour qui veut pouvoir modifier 'l'inventaire' du contenu du répertoire. Ce bit est nécessaire à un utilisateur pour effectuer les opérations suivantes dans le répertoire : créer ou effacer un fichier, renommer un fichier, introduire dans le fichier un nouveau fichier/sous-répertoire par déplacement, déplacer ailleurs un fichier/sous-répertoire. Voir page précédente pour les droits 'r-x'.

Index de la section - Index de la Base de Connaissances

Le bit setGID

Le bit setGID (le 's' ou parfois le 'S' qui dans la sortie de 'ls -l' occupe la position du bit d'exécution du groupe propriétaire) a une interprétation très particulière pour un répertoire. S'il est positionné cela implique que tout fichier créé dans le répertoire aura automatiquement le même groupe propriétaire que le répertoire lui-même.
Ceci peut être utile au sein d'une grande organisation pour centraliser les fichiers concernant un projet auquel participent un certain sous-ensemble d'utilisateurs.
Dans ce cas, vous créez en tant qu'administrateur du système un groupe pour ce projet disons le groupe 'projetmachin', vous faites de ce groupe le groupe propriétaire du répertoire, vous ajoutez les utilisateurs concernés par ce projet au groupe 'projetmachin' et … vous positionnez le bit setGID sur le répertoire… De la sorte vous serez sûr que tout fichier créé dans ce répertoire sera utilisable par tout membre du 'projetmachin'.

Index de la section - Index de la Base de Connaissances

Le bit sticky

Ce bit est représenté par un 't' (ou parfois par un 'T') qui occupe la position du bit d'exécution des 'autres utilisateurs'.
Il concerne de nos jours uniquement des répertoires.
Lorsque ce bit est positionné, il assure qu'un fichier qui se trouve dans le répertoire ne pourra être supprimé que par son propriétaire. Ce bit peut être combiné avec le bit setGID (voir paragraphe précédent). Un autre type d'emploi classique peut être illustré par le répertoire '/tmp' de votre système. N'importe quel utilisateur doit pouvoir y créer des fichiers temporaires et les utiliser par la suite (le plus souvent sans le savoir, par l'entremise des processus qu'il a lancés). Mais il est nécessaire que chaque utilisateur puisse être "sûr" d'y retrouver ce qu'il y a mis, d'où l'utilité de positionner le bit sticky pour ce répertoire dont les permissions seront affichées ainsi dans la sortie de ls -l :

drwxrwxrwt

Permissions en majuscules ou en minuscules ?

Etant donné que dans la représentation usuelle les bits setUID, setGID et sticky occupent la position du bit d'exécution, comment savoir si ce dernier est positionné ? La réponse est simple et obéit à la convention suivante :

• si le bit setUID, setGID ou sticky est représenté par une minuscule ('s' ou 't') alors le bit d'exécution correspondant à la position qu'il occupe est positionné (x)
  
• si le bit setUID, setGID ou sticky est représenté par une majuscule ('S' ou 'T') alors le bit d'exécution correspondant à la position qu'il occupe n'est pas positionné (-)
  

Les permissions attribuées lors de la création d'un fichier : le masque de permissions ou "umask"

Au point où vous en êtes maintenant vous savez que tout fichier Linux possède un jeu de permissions pour son propriétaire, pour son groupe et pour l'ensemble des autres utilisateurs.

Qu'en est-il donc lorsque je crée moi-même un fichier, pourriez-vous alors vous demander… et lorsque 'root' crée un fichier, qu'en est-il ?

Vous savez que le propriétaire du fichier est toujours le créateur du fichier et que le groupe propriétaire du fichier sera le groupe (principal) de cet utilisateur, certes, mais les permissions, comment sont-elles attribuées ?

Eh bien, le système doit posséder, pour chaque utilisateur, un ensemble de permissions par défaut, qui sont attribuées aux fichiers créés par cet utilisateur. C'est ce que définit le "masque de permissions" encore appelé "umask".

Pour savoir quelles sont ces permissions pour un utilisateur donné, connectez-vous sous son identité et lancez la commande 'umask -S'. L'option '-S' provoque un affichage non numérique du type de celui que vous avez appris à interpréter et à utiliser dans la section consacrée à chmod, où 'u' représente le propriétaire du fichier (son utilisateur comme on dit aussi parfois), 'g' son groupe propriétaire et 'o' les autres utilisateurs du système. Vous pourrez donc obtenir quelque chose comme celà :

umask -S
u=rwx,g=rx,o=rx

ce qui signifie que le propriétaire du nouveau fichier aura les droits de lecture-écriture-exécution sur le fichier et que tous les autres utilisateurs auront les droits de lecture-exécution. Sur mon système ce sont là les valeurs de 'umask' pour moi-même, et aussi pour 'root'.

Si maintenant vous lancez, dans le même environnement, la commande 'umask' sans l'option '-S', vous obtiendrez ceci :

umask
0022

hum… bizarre… Vous obtenez en fait un nombre octal. C'est ce qu'indique le '0' initial, qui ne varie pas. Les trois autres chiffres correspondent respectivement aux permissions du propriétaire, du groupe et des autres, comme d'habitude… Mais d'une façon un peu étrange : pour retrouver les valeurs numériques qui représentent les permissions lorsqu'on utilise chmod (si vous avez oublié cela commencez par réviser un peu...), il faut soustraire de 7 le chiffre de l'umask. Comment ? Que dites-vous ? Voyons cela de plus près. Examinons d'abord le cas du propriétaire du fichier. Dans l'umask il a pour valeur '0' (c'est le premier chiffre après le '0' initial, vous vous rappelez ?). Or '7-0=7' n'est-ce pas? Donc, les permissions du propriétaire sont représentées par '7' dans le système chmod et vous savez que '7' représente les permissions maximales : 'rwx'. Le propriétaire a donc bien les droits de lecture, écriture et exécution.
Pour le groupe, et aussi pour les autres utilisateurs, le chiffre de l'umask est '2'. Or '7-2=5' et '5', dans le système chmod, c'est 4+1 (si si), autrement dit lecture+exécution, soit 'rx'.
Nous retrouvons donc bien les mêmes résultats qu'avec l'option '-S' - même si c'est de façon passablement tortueuse. Nous disposons donc de deux façons de déterminer les permissions par défaut pour un utilisateur, lancer 'umask -S' ou lancer 'umask'.

La commande 'umask' permet aussi de changer les permissions par défaut. Utilisez cela avec précaution et seulement si vous savez vraiment ce que vous faites, car en principe les valeurs par défaut choisies par votre distribution devraient être satisfaisantes.

Si vous faites :

umask 0002

les permissions par défaut donneront désormais, pour les fichiers qui seront créés, les droits de lecture-écriture-exécution (7-0=7) au propriétaire mais aussi, cette fois, au groupe, tandis que les autres utilisateurs auront seulement les droits de lecture et écriture (7-2=5). Des permissions pour l'ensemble des utilisateurs d'un système peuvent ainsi être définies dans le fichier de configuration du shell '/etc/bashrc' (regardez donc si vous trouvez dans le vôtre des lignes qui contiennent 'umask', mais attention ne modifiez pas cela inconsidérément, si vous mettiez cet 'umask' à la valeur 777 vous risqueriez de ne plus pouvoir vous reconnecter...).

Notez enfin qu'il est aussi possible d'attribuer un 'umask' à une partition entière par le biais de l'entrée qui concerne cette partition dans le fichier '/etc/fstab', voir là-dessus Lea-Linux - Montage de disques : /etc/fstab.

Nous ne sommes pas encore tout à fait au bout de nos peines, à vrai dire. Comme vous le savez la permission d'exécution n'a de sens et d'intérêt que pour un fichier dont le contenu est… exécutable, elle n'a pas de sens pour des fichiers de données brutes. D'autre part, il n'est pas toujours souhaitable qu'un fichier exécutable le soit par défaut, pour des raisons de sécurité. Pour ces raisons, le système, le plus souvent, n'attribue pas la permission d'exécution même quand elle est prévue par l'umask… C'est pourquoi on vous recommande généralement, dans les documentations, de rendre exécutable un fichier de script que vous venez de créer. Même si votre 'umask' donne 'théoriquement' le bit d'exécution au propriétaire du fichier, dans la pratique, il n'est le plus souvent pas attribué à la création du fichier… Vous pourrez vérifier tout cela pour votre cas personnel en créant différentes sortes de fichiers et en examinant les permissions qui leur auront été attribuées.

Pour terminer notez que l'umask a parfois une incidence sur la façon dont la commande 'chmod' est exécutée. Il est en effet possible de lancer cette commande sans préciser explicitement à quels types d'utilisateurs les permissions mentionnées s'appliqueront. Par exemple on peut faire ceci :

chmod +w choin

Dans un tel cas la permission d'écriture (w) sera attribuée aux utilisateurs pour lesquels l'umask prévoit cette permission. Autrement dit si vous appliquez cette commande à un fichier 'choin' qui possède les permissions '-r-xr-xr-x' et si votre umask est u=rwx,g=rx,o=rx. Les permissions de 'choin' après exécution de 'chmod' deviendront ceci :

ls -l choin
-rwxr-xr-x

le droit d'écriture n'est attribué qu'au propriétaire, seul droit d'écriture prévu par l'umask.

Notez que vous pouvez attribuer ce droit à d'autres utilisateurs, il vous suffira d'utiliser une version plus 'explicite' de 'chmod', par exemple la lettre 'a' vous permettrait d'accorder ce droit à tous les utilisateurs sans que l'umask joue alors le moindre rôle :

chmod a+w choin
ls -l choin
-rwxrwxrwx

Le choix du masque de permissions pour 'root' et pour les simples utilisateurs fait partie des réglages de sécurité du système (voir la commande "draksec", onglet "options système").

Index de la section - Index de la Base de Connaissances

Autres ressources

Index de la section - Index de la Base de Connaissances