Permissions
De Wiki de la communauté Mandriva.
Introduction
La notion de permission
Linux reconnaît les utilisateurs à leur compte.
Pour utiliser votre système, vous devez d'abord lui dire qui vous êtes (autrement dit à quel compte vous voulez accéder) au moment où vous vous connectez (ou, comme on dit parfois aussi, en imitant le terme anglais to log, au moment où vous vous loguez). Lorsque vous l'avez fait, le système vous place d'emblée dans le répertoire personnel de votre compte (/home/nom_de_compte), où vous pouvez faire à peu près tout ce qui vous passe par la tête.
Tout système UNIX a en outre un compte « humain » particulier pré-configuré, le compte root. Le compte root présente des particularités bien marquées : son répertoire personnel est /root (le répertoire personnel de root n'est donc pas situé dans le répertoire /home, contrairement aux répertoires personnels des simples utilisateurs) et, d'autre part, quiconque est root possède un contrôle total sur le système.
Derrière ce schéma, il y a l'idée de séparer radicalement l'utilisation quotidienne d'un système d'exploitation de l'exécution des tâches d'administration du système. Entre autres choses, ceci présente l'intérêt d'éviter qu'une erreur commise au cours de l'utilisation normale du système d'exploitation puisse avoir des conséquences graves sur le système d'exploitation lui-même.
Cela permet aussi de faire coexister différents utilisateurs sur le même système. Ces utilisateurs ne sont, d'ailleurs, pas toujours humains : des services du système possèdent souvent des comptes qui leur sont propres, et n'ont pas alors à être lancés par le « superutilisateur root ». De la sorte un service du système mal configuré ne sera pas lui non plus en état d'avoir un impact dommageable important sur le système d'exploitation.
Mais, comment donc le système d'exploitation détermine-t-il qui est autorisé à faire quoi ? C'est ici que les permissions entrent en scène.
Dans un système UNIX, chaque fichier est doté d'un ensemble de permissions. Dans la liste de fichiers obtenue à l'écran par la commande ls employée avec l'option -l, les informations pertinentes pour les permissions sont pour chaque fichier :
- les neuf caractères qui suivent le premier caractère de la ligne consacrée au fichier
- le nom de son propriétaire
- le nom de son groupe propriétaire.
(Attention : dans le contexte d'une discussion sur les permissions l'expression « utilisateur du fichier machin » peut être prise comme synonyme de « propriétaire du fichier machin » (et dans le même contexte en anglais user (utilisateur) sera parfois à comprendre comme owner (propriétaire)).
Le premier caractère ne concerne pas directement les permissions, il correspond au type du fichier« : d pour un répertoire, - pour un fichier ordinaire (on dit régulier), l pour un lien symbolique etc.
Cela donnera, par exemple, quelque chose qui pourra ressembler à cela :
-rw-rw--r-- (...) propriétaire groupe (...) fichier
Plus concrètement, pour le fichier choin.txt, appartenant à l'utilisateur toto et au groupe de toto, cela pourra donner :
-rw-rw-r-- 1 toto toto 7231 jan 17 13:30 choin.txt
Le nom de l'utilisateur et de son groupe (toto dans les deux cas dans notre exemple), ainsi que le nom du fichier (choin.txt) sont clairement visibles ; reste à savoir ce que signifient au juste les dix premiers caractères... Nous savons déjà que le premier (ici : -) représente le type du fichier, dans notre cas un simple fichier régulier. Nous aborderons la signification des neuf caractères suivants dans la suite de cette page.
Sous UNIX tout se traite en termes de fichiers, même l'accès à des périphériques (par l'entremise des fichiers spéciaux du répertoire /dev) tels que les imprimantes, les modems, les cartes son etc. Si vous ne disposez pas de permission pour un fichier qui représente un périphérique vous ne pourrez pas l'utiliser.
Le premier concept en jeu dans les permisssions est celui de propriété. Vous êtes le propriétaire d'un fichier ou d'un répertoire que vous avez créé ou bien qui vous a été « remis » par l'entremise de la commande chown (une abréviation pour change owner, autrement dit changer le propriétaire, une commande sur laquelle nous reviendrons). Si vous possédez un fichier, vous pouvez, en général, en faire ce que vous voulez.
Mais, bien souvent, plus d'un titulaire de compte a besoin d'accéder à un fichier ou à un périphérique. Changer le propriétaire d'un tel fichier chaque fois que quelqu'un en a besoin serait pour le moins lassant. C'est pourquoi la propriété d'un fichier n'est pas seulement attribuée à des comptes particuliers mais aussi à des groupes. Les groupes sont définis dans le fichier /etc/group, une entrée de ce fichier ressemble à ceci :
nom_du_groupe:x:ID_du_groupe:membres_du_groupe
(vous pouvez y jeter un coup d'œil, juste par curiosité, en faisant, en console : cat /etc/group | less ou en sélectionnant seulement les lignes qui vous concernent : si votre nom d'utilisateur est toto utilisez la commande grep ainsi : grep toto /etc/group).
Pour voir une liste des groupes auxquels votre compte appartient, lancez la commande :
Si donc vous êtes membre d'un groupe et si ce groupe possède des permissions sur un fichier, vous pouvez faire quelque chose de ce fichier, même si vous n'en êtes pas le propriétaire.
Un système UNIX comprend en moyenne quelque chose comme 60.000 fichiers ou davantage. La majorité d'entre eux doivent être accessibles de quelque façon à tous les utilisateurs du système. Mais les permissions ne déterminent pas seulement qui a accès à un fichier, mais aussi quel genre d'accès est autorisé, et il y a de nombreux cas où des membres d'un certain groupe doivent disposer de droits importants sur un fichier tandis que les autres utilisateurs n'ont besoin que d'un accès limité à ce fichier. C'est pourquoi on a créé aussi la catégorie générale des « autres utilisateurs » (anglais others, parfois désigné comme « le reste du monde »...). Les permissions sur un certain fichier qui sont accordées à ce « groupe » très particulier sont en fait accordées à l'ensemble des utilisateurs autres que le propriétaire ou les membres du groupe propriétaire. Regardons encore une fois cet exemple :
-rw-rw-r–– (...) propriétaire groupe (...) fichier
Les caractères 2 à 4 (rw-) décrivent les permissions du propriétaire, les caractères 5 à 7 (rw-) décrivent les permissions des membres du groupe propriétaire, et les caractères 8 à 10 (r--) décrivent les permissions que tous les autres utilisateurs possèdent sur ce fichier.
Passons maintenant de l'identité des propriétaires à la nature des permissions qui leur sont accordées. Avec un fichier, on peut faire toutes sortes de choses : on peut le lire, le modifier, l'effacer (autrement dit le supprimer) ou - dans certains cas - l'exécuter. Ce sont les permissions qui déterminent lesquelles de ces actions seront possibles. Nous avons là affaire à la notion d'accessibilité.
Les permissions d'accès à un fichier peuvent être de trois types :
- permission de lire (marquée par un r, de l'anglais read)
- permission d'écrire et d'effacer (marquée par un w, de l'anglais write)
- permission d'exécuter (marquée par un x, de l'anglais execute).
Dans l'exemple qui précède, le propriétaire et le groupe du propriétaire ont la permission de lire et de modifier/effacer le fichier. Tous les autres utilisateurs peuvent lire le fichier mais ne peuvent rien changer à son contenu.
Et personne ne peut exécuter ce fichier. A la différence de ce qui se passe sous d'autres système d'exploitation, comme Windows, un fichier, pour pouvoir être exécuté, ne doit pas seulement avoir un contenu exécutable (binaire ou script), il doit aussi avoir le « bit d'exécution » (x) positionné. Ceci permet d'empêcher certains utilisateurs de lancer le fichier ou le programme, en général pour renforcer la sécurité du système. Même le superutilisateur root ne peut pas exécuter des fichiers qui n'ont pas le bit d'exécution positionné, mais bien entendu root peut rendre le programme exécutable. Et il va de soi que si le contenu du fichier n'est pas exécutable, il sera impossible de l'exécuter, quel que soit le statut du bit d'exécution.
Les répertoires eux aussi possèdent des permissions. De par la nature des répertoires, les permissions ont pour eux un sens un peu différent : r-x signifie qu'il est possible d'afficher la liste du contenu du répertoire (r) et d'en faire son répertoire de travail, d'y pénétrer (x). Et rwx signifie que l'on est autorisé en outre à y introduire des fichiers nouveaux ou à faire disparaître les fichiers qu'il contient. Toute autre combinaison de permissions ne vous permettra pas d'accéder pleinement à ce répertoire. Des détails sur les permissions des répertoires seront exposés dans cette section.
(Notez que sous Mandriva les permissions par défaut accordées aux fichiers et à certains répertoires peuvent différer de façon importante selon le niveau global de sécurité choisi pendant l'installation ou plus tard. Sur les niveaux de sécurité, voir ici et là).
Pourquoi il est important de comprendre les permissions
L'une des caractéristiques des systèmes Unix/Linux est de gérer toutes les opérations d'entrée/sortie par l'entremise de fichiers. Si, par exemple, vous envoyez un fichier à votre imprimante, vous l'envoyez en fait au fichier /dev/lp0. Si vous vous connectez à la Toile par modem, toutes les données sont lues et écrites dans le fichier /dev/ttyS0 (ou S1/S2/S3).
Il s'ensuit que ou bien vous ou bien le programme que vous exécutez devez/doit avoir la permission de lire ce fichier ou d'y écrire. Sinon, cela ne marchera pas. Il en va de même pour les répertoires : vous ne pourrez pas exécuter un programme qui se trouve dans un répertoire auquel vous n'avez pas accès ou qui a besoin d'écrire dans un répertoire auquel vous n'avez pas accès. Bien des problèmes de configuration sont simplement dus à des mauvaises permissions. Bien comprendre les permissions est donc très important pour régler bon nombre de problèmes.
Vous pourriez, bien sûr, vous dire que, comme vous êtes le seul utilisateur de votre machine, vous n'avez pas besoin de vous ronger les sangs pour toutes ces histoires de permission et que vous n'avez qu'à rester root en permanence et que comme ça, vous pourrez faire tout ce que vous voudrez.
Mais c'est justement pour cette raison que vous ne devez pas faire cela. Une seule commande erronée, sous root, peut mettre votre système en pièces, alors que, comme simple utilisateur vous ne pouvez pas détruire quoi que ce soit de vital pour le système. Vous devez donc absolument utiliser ce mécanisme protecteur, et ceci tout particulièrement si vous êtes un débutant.
Mais il y a plus encore : la plupart des programmes que vous lancerez sont exécutés avec les permissions de l'utilisateur qui les a lancés. Ainsi, lorsque vous démarrez un programme en qualité de simple utilisateur, il ne peut pas faire beaucoup de mal car il n'a pas les permissions qui seraient nécessaires pour cela. Mais il n'en irait pas de même avec un programme qui serait doté des privilèges de root… Vous le comprenez certainement sans peine...
La permission d'exécution rend un fichier exécutable. Beaucoup de fichiers écrits dans un langage de script, comme Perl ou même de simples scripts en shell en ont donc besoin. Si vous téléchargez un script et qu'il ne fonctionne pas, vérifiez d'abord si le bit d'exécution est positionné (sur cela voir la section suivante).
Certains programmes peuvent être exécutés avec l'id (UID=identifiant numérique de l'utilisateur) d'un autre utilisateur. Il arrive que des programmes aient besoin des privilèges de root même quand c'est un simple utilisateur qui les lance (c'est le cas par exemple du serveur X via le Xwrapper de /usr/bin/Xwrapper), de tels programmes sont marqués par un s (ou plus rarement un S), dans la position du bit d'exécution du propriétaire :
-rws--x--x 1 root root 5868 mar 22 17:47 /usr/X11R6/bin/Xwrapper*
(l'astérisque * en fin de ligne indique que nous avons affaire à un programme exécutable, sa présence est due à l'option -F de la commande ls, imposée invisiblement par un alias de Mandriva).
Le bit s (ou S) est appelé setUID ou SUID. Les programmes qui le possèdent créent une menace pour la sécurité, car des personnes mal intentionnées pourraient alors obtenir indirectement des privilèges de root. Il est donc conseillé de recourir le moins possible à ce mécanisme et de veiller alors aux alertes de sécurité. Notez que Linux refusera d'exécuter des scripts dotés du SUID. Nous revenons plus bas sur cet aspect des choses.
Compliqué tout cela, n'est-ce pas ;-) Eh bien jetez donc un coup d'œil à quelques exemples...
Quelques exemples concrets
Vous êtes perdu ? :) Eh bien peut-être que les choses vont s'éclaircir un peu pour vous si vous regardez de près quelques exemples tirés de la « vie courante ».
L'exemple de locate
locate est un programme Unix traditionnel, qui permet de trouver l'emplacement de certains fichier. Voici un exemple d'emploi de ce programme :
/usr/lib/firefox-2.0.0.12/mozilla-firefox-bin
Sous la Mandriva, locate appartient au paquetage mlocate. Si ce paquetage est installé sur votre système locate devrait être disponible.
locate va nous permettre d'illustrer le fonctionnement des permissions.
Les fichiers : l'exemple de l'exécutable updatedb
Ouvrez un terminal et tapez donc :
updatedb est un programme qui met à jour la base de données de (m)locate. Vous devriez obtenir quelque chose comme ceci :
-rwxr-xr-x 1 root root 30580 2007-09-24 17:26 /usr/bin/updatedb*
Nous avons d'abord besoin de savoir quel est le propriétaire de ce fichier et à quel groupe il appartient. Ces informations se trouvent, dans notre exemple, juste après le chiffre 1 (si vous êtes curieux de savoir ce que représente ce chiffre, voyez Liens, liens symboliques et liens en dur#« Voir » la différence..., mais il s'agit là d'une tout autre histoire...) :
root root
Le propriétaire est donc root, et le nom du groupe propriétaire est aussi root.
Qu'en est-il des permissions ?
Le premier caractère, qui est dans notre exemple un tiret (-), indique de quel type de fichier il s'agit (en l'occurrence un fichier ordinaire, ou régulier) : il ne nous concerne pas directement ici.
Les neuf caractères suivants décrivent les droits d'accès :
| Propriétaire | Groupe | Autres |
|---|---|---|
| rwx | r-x | r-x |
Rappel : r signifie « lecture » (anglais read), w signifie « écriture » (anglais write), et x signifie exécution (anglais execute). - signifie « non positionné » autrement dit « pas de droit ». L'ordre dans lequel apparaissent les droits est toujours rwx. Finalement, nous pouvons donc décoder ainsi la chaîne de caractères précédente :
- ce fichier peut être lu, modifié (ou effacé) et aussi exécuté par son propriétaire, c'est le sens de rwx.
- les membres du groupe propriétaire peuvent lire et exécuter le fichier, mais ils ne peuvent le modifier, c'est ce qu'indique la première chaîne de caractères r-x.
- tous les autres utilisateurs peuvent lire et exécuter le fichier, mais ils ne peuvent le modifier, c'est ce qu'indique la seconde chaîne de caractères r-x.
Conclusion : En tant que simple utilisateur vous avez parfaitement le droit d'exécuter ce programme. En dépit du fait qu'il ne vous appartient pas...
Les répertoires : l'exemple de /var/lib/mlocate
Facile tout cela, n'est-ce pas ?
Nous venons de voir à la section précédente que les permissions de updatedb :
-rwxr-xr-x 1 root root 30580 2007-09-24 17:26 /usr/bin/updatedb*
autorisent tout utilisateur à lancer cette commande.
Pourtant, si maintenant vous tentez de lancer le programme updatedb comme simple utilisateur, vous obtenez un message d'erreur :
updatedb: can not open a temporary file for `/var/lib/mlocate/mlocate.db'
(ce qui signifie : impossible d'ouvrir un fichier temporaire pour`/var/lib/mlocate/mlocate.db')
La base de données de mlocate se trouve dans le répertoire /var/lib/mlocate. Regardons un peu :
drwxr-x--- 2 root slocate 4096 2008-02-27 04:02 /var/lib/mlocate//
(pour obtenir les propriétés du répertoire lui-même notez que nous avons utilisé la commande ls avec l'option -d)
Pour comprendre ce que cela implique au juste, donnons d'abord une petite explication à propos de chacun des principaux cas de figure que l'on rencontre dans le domaine des permissions pour un répertoire :
- rwx : comme vous vous en doutez, avec cette combinaison de permissions, le répertoire est pleinement utilisable, on peut en afficher le contenu, lire, modifier ou exécuter les fichiers qu'il contient, pénétrer dans les sous-répertoires, supprimer ou déplacer ailleurs fichiers et sous-répertoires, créer ou faire venir d'ailleurs par déplacement de nouveaux fichiers et sous-répertoires… Bref tout est possible.
- --- : là c'est l'inverse, on ne peut rien faire, on ne peut pas même afficher le contenu du répertoire, on ne peut ni lire, ni modifier, ni exécuter les fichiers qu'il contient, on ne peut rien ajouter ou supprimer et on ne peut pénétrer dans les sous-répertoires. Une protection parfaite pour des données ou des exécutables que vous voulez mettre strictement « à l'abri ».
- r-x : ici, attention, c'est un peu surprenant au premier abord, vous pouvez afficher le contenu du répertoire (r) et y pénétrer pour en faire votre répertoire de travail (x), mais il vous sera impossible de supprimer ou de créer un fichier ou un répertoire qui serait à la racine du répertoire en question
Revenons maintenant à notre exemple.
Les droits sur le répertoire /var/lib/mlocate (rwxr-x---) se présentent ainsi :
- Le propriétaire (qui est ici le superadministrateur root) a le droit de pénétrer dans ce répertoire et d'y travailler (x), d'en afficher le contenu (r) et d'ajouter ou de supprimer des éléments de ce contenu (w)
- Les membres du groupe propriétaire (qui est ici le groupe slocate) peuvent afficher le contenu de ce répertoire (r) et en faire leur répertoire de travail (x), mais ils ne peuvent ni ajouter ni supprimer des fichiers ou des sous-répertoires.
- Les autres utilisateurs n'ont absolument aucun droit (---).
Etant donné que vous n'êtes ni root, ni membre du groupe slocate, vous rencontrez un problème lors de l'exécution d'updatedb parce que updatedb modifie le contenu de /var/lib/mlocate et que vous ne disposez pas des droits nécessaires pour cela.
Et, pour faire bonne mesure, le fichier de base de données lui-même ne vous est du reste accessible ni en lecture ni en écriture: :
-rw-r----- 1 root slocate 15100325 2008-02-27 04:02 /var/lib/mlocate/mlocate.db
Nous sommes donc ici dans le cas où vous pouvez lancer une certaine application (en l'occurrence updatedb), vous en avez le droit, MAIS les choses ne marchent pas malgré tout parce que cette application doit elle-même créer ou modifier un fichier sans que vous ayez les droits indispensables pour cela.
Cela dit, au point où nous en sommes, il se pourrait bien que la question suivante vous vienne à l'esprit : « Si je n'ai pas accès à la base de données de (m)locate, comment diable se fait-il que je puisse exécuter locate en tant que simple utilisateur ? Cette commande doit sûrement avoir besoin d'accéder à cette base de données ! » Et, ma foi, vous avez parfaitement raison de vous poser cette question... La réponse à cette question va bientôt venir...
Avant de poursuivre, si vous êtes particulièrement intéressé par les permissions concernant les répertoires notez que vous trouverez d'autres informations ici : Complément sur les permissions pour un répertoire, et une application au cas des permissions pour le répertoire personnel ici : #Quelles permissions pour mon répertoire personnel ?.
setUID, setGID
setGID : l'exemple de l'exécutable locate
Intéressons-nous maintenant au programme locate, qui est situé dans le répertoire /usr/bin.
Si vous lancez ls -l /usr/bin/locate, pour examiner les propriétés de ce programme, vous obtiendrez quelque chose de ce genre :
-rwx--s--x 1 root slocate 30520 2007-09-24 17:26 /usr/bin/locate*
Notez que s remplace x dans la zone correspondant aux droits d'exécution du groupe propriétaire.
Ceci signale un autre mécanisme important, dont vous avez peut-être déjà entendu parler : le mécanisme de setUID ou, ici, setGID. Ce mécanisme permet à des utilisateurs d'exécuter un programme avec un ID (identifiant) d'utilisateur ou de groupe différent du leur.
Chaque compte (chaque utilisateur) et chaque groupe possède un unique numéro d'ID, car les systèmes d'exploitation préfèrent avoir affaire à des nombres plutôt qu'à des noms. Vous utilisez des noms mais le système les traduit en nombres. Vous n'avez pas à vous en soucier, cela se fait « tout seul » et je mentionne cela simplement pour vous expliquer l'origine des termes setUID et setGID (qui signifient quelque chose comme « fixer l'UID (= l'identifiant numérique d'utilisateur) » et « fixer le GID (= l'identifiant numérique de groupe) ». Si tout cela pique votre curiosité, lancez donc :
Les permissions du programme locate permettent à n'importe quel utilisateur de le lancer (les « autres utilisateurs » ayant le droit d'exécution x).
Le point important pour nous ici est que si vous lancez en tant que simple utilisateur locate, le bit setGID de l'exécutable locate fait croire au système que vous êtes membre du groupe slocate et vous donne donc accès en lecture et exécution à /var/lib/mlocate, comme le garantissent les propriétés de ce répertoire :
drwxr-x--- 2 root slocate 4096 2008-02-27 04:02 /var/lib/mlocate//
(vous voyez en effet que le groupe propriétaire de notre répertoire est bien slocate et que ce groupe possède pour ce répertoire les droits de lecture et d'exécution)
Le bit 'setGID' vous donne aussi accès en lecture et écriture au fichier de base de données de locate , mlocate.db:
-rw-r----- 1 root slocate 15100325 2008-02-27 04:02 /var/lib/mlocate/mlocate.db
Pour résumer : un fichier de programme qui possède le bit setGID est exécuté avec les droits des membres de son groupe propriétaire, même si l'utilisateur qui l'a lancé n'appartient pas à ce groupe.
Dans notre exemple : grâce à un usage judicieux de setGID et du groupe slocate le fichier de données mlocate.db est consultable par tous les utilisateurs MAIS seulement à condition qu'ils utilisent pour cela le programme locate.
Un bel exemple de ce que le système des permissions de Linux rend possible.Associé à un répertoire, et non comme ci-dessus à un simple fichier, le bit setGID a une interprétation particulière, voir là-dessus cette section.
Les trois sections suivantes contiennent les indications nécessaires pour attribuer ou supprimer le bit setGID : #Changer les permissions par l'interface graphique, #Utiliser chmod avec des lettres, #Utiliser chmod avec des valeurs numériques.
setUID : l'exemple de Xwrapper
Le mécanisme est voisin pour les programmes qui sont dotés du bit setUID - qui concerne généralement l'identifiant de root - comme le programme Xwrapper qui lance l'interface graphique X :
-rwsr-xr-x 1 root root 5896 2008-01-22 21:17 /usr/bin/Xwrapper*
Vous remarquez que s remplace, cette fois, le bit d'exécution de l'utilisateur.
Démêlons un peu les choses en ce qui concerne ce fichier Xwrapper, étape par étape.
La sortie de ls -l Xwrapper nous montre que son propriétaire est root. Bon.
Vous pouvez toutefois l'exécuter parce que, comme le montre aussi la sortie de ls -l, le bit d'exécution (x) est positionné pour les « autres utilisateurs », catégorie à laquelle vous appartenez vous-même en tant que simple utilisateur. Bien.
De plus, la sortie de ls -l vous montre aussi que ce fichier est doté du bit setUID (s), qui a pour effet que quiconque lance Xwrapper sera doté des privilèges de son propriétaire, en l'occurrence root, pendant l'exécution de ce programme.
Voilà donc comment, en définitive, il a été possible de faire croire au système d'exploitation que vous êtes root lorsque vous lancez X. L'intérêt de la chose est que ce programme vous permet d'exécuter X et des applications de X sans que vous soyez vous-même root.
Les trois sections suivantes décrivent différentes procédures permettant d'attribuer ou de supprimer le bit setUID : #Changer les permissions par l'interface graphique, #Utiliser chmod avec des lettres, #Utiliser chmod avec des valeurs numériques.
Lorsque vous lancez un programme qui possède le bit setUID vous vous trouvez doté temporairement des privilèges du propriétaire du programme pendant son exécution.
Comment modifier les permissions en console
Souvenez-vous que la notion de permission recouvre deux concepts : la propriété et l'accessibilité.
Il y a donc essentiellement deux façons d'agir sur les permissions :
- modifier le propriétaire et/ou le groupe propriétaire à l'aide de la commande chown (de l'anglais CHange OWNer = changer le propriétaire) - ou éventuellement avec la commande chgrp (de l'anglais CHange Group)
- modifier l'accessibilité à l'aide de la commande chmod (de l'anglais CHange MODus = changer les modalités d'accessibilité).
Vous trouverez ci-dessous des indications sur la façon dont on doit s'y prendre pour modifier les permissions en ligne de commande, nous décrivons plus loin comment modifier les permissions par l'interface graphique.
Changer de propriétaire à l'aide de chown et chgrp
chown est une commande assez facile à utiliser :
fait de jules le propriétaire du fichier essai.txt et du groupe utilisateurs le groupe propriétaire de ce fichier (remarquez bien les : qui séparent les deux indications dans la commande).
Si vous êtes un simple utilisateur (et non le superutilisateur root) vous ne pourrez pas modifier le propriétaire d'un fichier, même s'il vous appartient !
En outre, en tant que simple utilisateur, vous ne pourrez modifier le groupe propriétaire d'un fichier que si le fichier vous appartient et si le nouveau groupe est un groupe dont vous faites partie.
Seul root peut changer le propriétaire ou le groupe propriétaire d'un fichier qu'il ne possède pas lui-même.
Comment alléger chown... Si vous voulez à la fois changer le propriétaire d'un fichier et donner à ce fichier le groupe principal du nouveau propriétaire, comme si c'était lui qui l'avait créé, il n'est pas nécessaire de mentionner le groupe. Par exemple pour donner le fichier secrets.txt à root et au groupe de root (lequel s'appelle aussi root), vous taperez simplement :
à la place de :
Si vous voulez changer uniquement le groupe propriétaire d'un fichier ou d'un répertoire utilisez la commande chgrp. Par exemple, pour attribuer le répertoire /var/spool/mail au groupe mail (au cas improbable où ce ne serait pas déjà le cas...), vous pourriez taper :
Avec les deux commandes, ces changements peuvent être « récursifs » (autrement dit s'appliquer aussi à tous les sous-répertoires du répertoire passé en argument à la commande et à tous les fichiers et répertoires qu'ils contiennnent), si vous ajoutez l'option -R :
fait de jules le propriétaire du répertoire doc et de tous les fichiers et répertoires contenus dans doc, et fait aussi du groupe utilisateurs le groupe propriétaire de chacun de ces fichiers et répertoires.
Modifier les propriétés d'accessibilité à l'aide de chmod
chmod est d'un maniement un peu plus délicat.
Utiliser chmod avec des lettres
Cette commande doit prendre en compte trois sortes d'utilisateurs : le propriétaire, les membres du groupe propriétaire et l'ensemble des autres utilisateurs. Ils correspondent respectivement, dans le langage de chmod, aux lettres : u, g, et o. u pour « utilisateur » (anglais user) : rappelez-vous que le terme « utilisateur » est souvent employé comme synonyme de « propriétaire » lorsqu'il est question de permissions), g pour « groupe », évidemment, et o pour « autres »… enfin pour others en anglais.
Et puis, il y a les trois sortes de droits : lecture (r), écriture (w) et exécution (x), soit au total et dans l'ordre habituel : rwx (cf. anglais read, write et execute).
La syntaxe de chmod (en simplifiant un peu) se présente comme suit :
chmod [ugo][+-][rwx] fichier
Imaginons que vous souhaitiez accorder (+) le droit de lecture (r) aux « autres utilisateurs » (o) du fichier essai.txt. Voilà comment vous devez procéder :
Si maintenant vous souhaitez priver (-) les membres du groupe propriétaire (g) du droit d'exécuter (x) le programme /usr/bin/lancemoi, vous devez faire :
Et il y a des chances que vous ayez besoin d'être root pour faire cela...
Si vous tenez à interdire (-) tout accès (rwx) au répertoire perso à tous les utilisateurs autres que son propriétaire, vous taperez :
chmod possède d'autres options bien utiles, par exemple, a (pour l'anglais all = tous). Ainsi :
accorde le droit de lecture au propriétaire, aux membres du groupe propriétaire et à tous les autres utilisateurs.
Une autre option utile est s qui permet d'accorder les bits setUID ou setGID :
accordera le bit setUID au fichier fichier et le rendra exécutable par tout le monde. Tandis que :
accorderait le bit setGID au fichier.
Lorsque chmod est employée sans indication d'utilisateurs, comme ceci :
la nature du résultat obtenu dépend de l'umask de l'utilisateur qui a lancé la commande. Si toto a lancé la commande, cela pourrait donner :
-rwxr-xr-x 1 toto toto 0 2008-02-27 17:07 fichier*
Comme chown, chmod peut être lancée récursivement avec l'option -R (attention il s'agit d'un R majuscule !). Mais regardez tout de même à ce sujet la section #Un cafouillage courant en matière de permissions.
Utiliser chmod avec des valeurs numériques
chmod permet aussi d'attribuer les différents droits en utilisant un codage numérique.
Les droits peuvent alors être représentés par une succession de trois chiffres
- le premier chiffre pour les droits du propriétaire
- le second pour ceux du groupe propriétaire
- le troisième pour les droits des autres utilisateurs.
Dans ce codage :
4 signifie « lecture » (r), 2 signifie « écriture » (w) et 1 « exécution » (x).
Quand plus d'un droit est attribué le chiffre indiqué est la somme des chiffres correspondant à ces différents droits, par exemple :
- 7 = 4+2+1 pour rwx
- 6 = 4+2+0 pour rw-
- 5 = 4+0+1 pour r-x
- 3 = 0+2+1 pour -wx
- 0 = 0+0+0 pour ---
Avec ce système, la commande :
attribuera donc au propriétaire du fichier monfichier les droits de lecture + écriture + exécution (4+2+1=7), au groupe propriétaire les droits de lecture + exécution (4+0+1=5), et aucun droit aux autres utilisateurs (0+0+0=0). Ce qui donnerait :
-rwxr-x--- 1 toto toto 0 2008-02-27 16:34 monfichier*
Un quatrième chiffre (qui est alors en fait le premier chiffre de la série !), permet de représenter, s'ils sont présents, les bits spéciaux :
setUID = 4, setGID = 2, bit sticky = 1
Le premier chiffre, sur une représentation numérique à quatre chiffre, est alors la somme des valeurs des différents bits spéciaux.
Et donc :
attribuerait au fichier monfichier les mêmes droits que dans l'exemple précédent, avec en plus le bit setUID :
-rwsr-x--- 1 root root 0 2008-02-27 16:34 monfichier*
et :
attribuerait le bit setGID ce qui donnerait :
-rwxr-s--- 1 root root 0 2008-02-27 16:34 monfichier*
Le répertoire /tmp, qui possède traditionnellement les permissions rwxrwxrwt (avec t pour le bit sticky), aurait les permissions 1777, soit :
drwxrwxrwt 5 root root 120 2008-02-27 08:00 /tmp/
Vous suivez ?
Comparaison des deux méthodes
Y a-t-il une différence de fond entre ces deux méthodes ? Eh bien oui. La première méthode positionne des droits de façon « relative », en ce sens qu'elle ajoute ou supprime des droits, tandis que la seconde positionne des droits de façon « absolue ».
Par exemple, s'il se trouve que nous sommes dans la situation suivante :
-rw-r----- 1 toto toto 248 2008-02-28 07:42 un.txt
et que maintenant nous souhaitions accorder aux « autres utilisateurs » le droit de lecture sur ce fichier, avec la première méthode nous ferions :
et nous obtiendrions :
-rw-r--r-- 1 toto toto 248 2008-02-28 07:46 un.txt
Avec la seconde méthode si par exemple nous faisons :
nous obtenons bien sûr :
-r--r--r-- 2 toto toto 0 2008-02-28 07:48 un.txt
La première méthode laisse le droit d'écriture du propriétaire inchangé. Mais lorsque nous utilisons la seconde méthode nous devons toujours spécifier les permissions absolues du propriétaire, du groupe et des autres pour parvenir au résultat souhaité, dans notre exemple nous devons donc faire :
On pourrait penser qu'il est de bonne pratique de vous concentrer sur l'une des deux méthodes pour ne pas tout mélanger, mais en fait, si vous lisez de la documentation et des scripts, vous rencontrerez les deux, et il reste donc utile de bien les connaître l'une et l'autre...
Nous signalerons enfin, pour que vous ne soyez pas surpris lorsque vous la rencontrerez, une façon d'attribuer des permissions absolues à l'aide de la notation par lettres, en utilisant le signe =.
Nous nous limiterons à quelques exemples qui vous permettront de comprendre de quoi il s'agit.
chmod u=rwx,g=rw,o=r /home/toto/choin.txt
Cette commande remplace les permissions précédentes du fichier, en les fixant à rwxrw-r--.
chmod u=rwx,g=r /home/toto/gruon.txt
Cette commande fixe les permissions à rwx pour le propriétaire et à r-- pour le groupe, en laissant intactes les permissions précédentes pour les autres utilisateurs. Enfin :
chmod u=rwx,g=r,o= /home/toto/chump.txt
fixe les permissions pour le fichier concerné à rwxr-----.
Un cafouillage courant : supprimer récursivement la permission d'exécution
Manipulez les permissions avec prudence ! Elles font partie intégrante de la gestion de la sécurité sous Linux et elle peuvent créer de sérieux problèmes lorsqu'elles sont mises en œuvre de façon irréfléchie. En voici un exemple.
Cet exemple concerne la permission d'exécution x. Le fait que cette permission puisse concerner tantôt des répertoires, tantôt des fichiers, mais avec dans les deux cas des significations bien différentes, peut créer des difficultés lorsque vous voulez ajouter ou ôter cette permission à tout un ensemble d'éléments.
Supposons, par exemple, que vous ayez copié un répertoire appelé texte, contenant comme son nom l'indique des fichiers texte, à partir d'une partition vfat de MS Windows. Du fait des différences entre les systèmes de gestion de fichiers, tous les fichiers du répertoire se retrouvent bizarrement dotés du bit d'exécution (x) alors qu'il ne s'agit pas de fichiers binaires. « Pas de problème », pensez-vous, et vous exécutez la commande suivante :
Et voilà qu'à votre première tentative de pénétrer dans ce répertoire vous n'obtenez d'autre résultat que l'affichage du message
bash: cd: texte: Permission denied
Vous passez en root par su et vous réessayez et derechef :
bash: cd: text: Permission denied
Que diable se passe-t-il donc ? Eh bien, vous n'avez pas seulement supprimé le bit d'exécution des fichiers situés dans le répertoire texte, vous l'avez aussi supprimé pour le répertoire lui-même !
Or il se trouve, vous devriez le savoir, que pour un répertoire le bit d'exécution est ce qui détermine si vous pouvez pénétrer ou non dans le répertoire en question ! Maintenant personne, pas même root ne peut donc plus pénétrer dans texte ! Pour remédier à cela, repositionnez simplement le bit d'exécution pour le répertoire texte :
(évidemment sans l'option -R !)
Comment auriez-vous dû procéder pour éviter cela ? Eh bien, lorsque vous avez un répertoire qui contient des fichiers dont vous voulez supprimer récursivement le bit d'exécution tout en empêchant chmod de modifier le bit du répertoire lui-même - et de ses sous-répertoires - vous devez pénétrer dans ce répertoire et faire quelque chose comme ceci :
Ceci permettra de trouver tous les fichiers réguliers (-type f), ce qui exclura les répertoires, et de leur appliquer (-exec) la commande chmod a-x.
Notez que, si vous vouliez attribuer la permission d'exécution à un répertoire et, dans la foulée, récursivement, à tous ses sous-répertoires, sans l'attribuer pour autant à quoi que ce soit d'autre et notamment à des fichiers qui ne seraient pas des programmes (sans l'attribuer donc à des fichiers de texte, à des images etc.). Vous pourriez faire quelque chose d'analogue et lancer :
(-type d assure ici que seuls des répertoires se verront attribuer la permission d'exécution)
Notez que cette manœuvre est plus rarement nécessaire que la précédente, car les répertoires sont en général par défaut déjà exécutables pour tous les utilisateurs.
Changer les permissions par l'interface graphique
La plupart des interfaces graphiques proposent des moyens intuitifs pour changer les permissions, le propriétaire et le groupe propriétaire d'un fichier ou d'un répertoire ou d'un ensemble de fichiers et de répertoires, nous prendrons, ici, pour exemple les dispositifs disponibles sous KDE, des techniques analogues sont disponibles dans les autres interfaces graphiques.
En outre Mandriva fournit un outil qui permet de créer des règles gérant les permissions pour des ensembles particuliers de répertoires ou de fichiers.
Sous KDE
Changer les permissions
Voici comment modifier les permissions d'un fichier ou d'un répertoire sous KDE.
- 1 Ouvrez Konqueror.
- 2 Pressez la touche F9 et naviguez jusqu'au(x) fichier(s) ou répertoire(s) dont vous souhaitez modifier les propriétés.
- 3 Sélectionnez le fichier, le répertoire, ou l'ensemble de fichiers ou de répertoires à modifier.
- 4. Faites un clic droit et choisissez Propriétés dans le sous-menu.
- 5. Ouvrez l'onglet Droits d'accès.
S'ouvre alors une boîte de dialogue très intuitive qui vous permet aisément de modifier les propriétés. N'hésitez pas à cliquer sur le bouton Droits d'accès avancés qui propose un tableau particulièrement clair de l'ensemble des propriétés et qui permet aussi éventuellement d'attribuer les « bits spéciaux » setUID, setGID et sticky.
Si le fichier ou le répertoire ne vous appartient pas, lancez Konqueror sous root comme indiqué à la section suivante.
Changer le propriétaire ou le groupe
Si vous voulez changer aussi le propriétaire ou le groupe propriétaire du fichier, vous devez lancer Konqueror sous root (et ceci, notez-le bien, même si le fichier vous appartient).
Pour cela, vous pouvez, par exemple, ouvrir une console graphique (utilitaires Konsole ou rXVT) et lancer la commande su. Ou plus simplement passer par la fenêtre <Alt+F2> : dans Commande tapez konqueror, puis faites Options > Exécuter sous un autre nom d'utilisateur.
Ensuite, vous procédez comme dans la section précédente et vous verrez que les zones de la boîte de dialogue contenant le propriétaire et le groupe propriétaire peuvent maintenant être modifiées.
Bien entendu, mieux vaut tout de même que vous sachiez ce que vous faites en effectuant de telles modifications, une lecture préalable des pages qui précèdent, est donc en tout état de cause recommandée...
Contrôler les permissions avec le Centre de Contrôle de Mandriva Linux
Mandriva vous offre la possibilité de créer, pour votre système, des règles de permissions qui assureront que, pour certains fichiers ou répertoires, l'identité du propriétaire et du groupe propriétaire et la gamme des permissions conservent certaines valeurs. Ces règles seront vérifiées toutes les heures par le système, si bien que, si les permissions ou les propriétaires ont été modifiés accidentellement ou par malveillance, vous pourrez être sûr qu'ils retrouveront les valeurs que vous souhaitez imposer dans un délai maximum de 60 minutes.
Vous trouverez un guide d'utilisation de ces fonctionnalités du Centre de Contrôle de Mandriva Linux (CCM) dans cette section du Wiki : Msec#Vérifier ou modifier permissions ou propriétaires.
Si vous modifiez « à la main » par la commande chmod ou par l'interface graphique, les permissions sur un fichier ou un répertoire auquel l'outil du CCM msecgui "force" l'application d'une règle de permission, il est certain que dans moins de 60 minutes les permissions imposées par l'outil du CCM msecgui seront rétablies ! N'oubliez pas cela ! Pensez, dans de tels cas, à modifier ou à créer les règles qui vous conviennent dans msecgui.
Complément sur les permissions pour un répertoire
Les permissions 'normales'
Nous avons indiqué sommairement plus haut 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.
La permission r pour un répertoire
- le bit de lecture (r) permet d'afficher le contenu du répertoire, plus précisément, il permet d'afficher la liste des fichiers et sous-répertoires qui sont à la racine du répertoire concerné.
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, en outre, notez bien que seuls les fichiers et sous-répertoires qui sont à la racine du répertoire doc/ seraient affichables, 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...
Une curiosité : les droits r--.
Essayons tout de même. Créons un répertoire /doc contenant un sous-répertoire Etampes. Créons aussi un fichier à la racine de chacun des deux répertoires. :
touch doc/liste.txt doc/Etampes/afaire.txt
(l'option -p permet de créer en une fois les deux répertoires).
Les permissions - normales - de doc/ sont :
drwxr-xr-x 3 toto toto 4096 2008-02-29 16:24 doc//
Je peux afficher le contenu de doc/ et de son sous-répertoire :
doc/:
Etampes/ liste.txt
doc/Etampes:
afaire.txt
Maintenant, je modifie les permissions de doc/ :
dr-------- 3 toto toto 4096 2008-02-29 16:24 doc//
Et j'essaie de regarder :
doc/:
Etampes/ liste.txt
ls: ne peut ouvrir le répertoire doc/Etampes: Permission non accordée
Le contenu du sous-répertoire doc/Etampes/est maintenant inaccessible (doc/ devrait avoir la permission x pour cela). Bien sûr, toute tentative de modifier le contenu de doc/ sera aussi vouée à l'échec :
bash: doc/liste.txt: Permission non accordée
Et je ne pourrai pas même lire le contenu du fichier doc/liste.txt (pour cela aussi il faudrait à doc/ la permission x) :
cat: doc/liste.txt: Permission non accordée
Les permissions r-- pourraient être utiles si doc/ contient des données immuables, confidentielles, qu'on a décidé d'archiver et qu'on pense n'avoir que rarement à consulter, mais sur l'inventaire général desquelles on veut pouvoir jeter un coup d'œil rapide pour se remémorer sans peine ce qu'elles contiennent... Pour être à nouveau en mesure de les consulter et les modifier, il suffirait du reste simplement de faire quelque chose comme chmod 700 doc/ sous l'identité du propriétaire de doc/.
La permission w pour un répertoire
- le bit d'écriture (w) pour un répertoire est indispensable pour modifier « l'inventaire » des fichiers ou sous-répertoires qui sont à la racine du répertoire en question. Ce bit est donc nécessaire à un utilisateur pour créer, effacer ou renommer un fichier ou sous-répertoire à la racine.
La permission r permet de voir l'inventaire des objets à la racine du répertoire, la permission w permet de modifier cet inventaire.
Pour le cas d'un répertoire ayant les droits r-x, et à qui il manque donc la permission w voir aussi #Les répertoires : l'exemple de /var/lib/mlocate. Illustrons ce cas en reprenant l'exemple de notre répertoire doc/, qui au départ, se présente ainsi :
drwxr-xr-x 3 toto toto 4096 2008-02-29 16:24 doc//
doc/:
Etampes/ liste.txt
doc/Etampes:
afaire.txtModifions ses permissions :
dr-x------ 3 toto toto 4096 2008-02-29 16:24 doc//
Maintenant, on ne pas peut plus effacer un fichier à la racine de doc/, mais il est parfaitement possible d'effacer un fichier qui est dans un sous-répertoire de doc/ !!
rm: ne peut enlever `doc/liste.txt': Permission non accordée
total 0
La permission x pour un répertoire
- 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, de modifier et de lire les fichiers qu'il contient.
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 et répertoires de doc/ (s'ils disposent eux-mêmes des permissions appropriées), mais vous ne pouvez pas afficher le contenu de doc/ faute du bit r… vous travaillez donc « à l'aveuglette ». Naturellement, ce n'est pas impossible (on peut vous avoir 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).
Pour l'attribution de telles permissions au répertoire personnel, voir #Permettre un accès limité : 711.
Pour une application de ces notions sur les permissions au cas du répertoire personnel, voir #Quelles permissions pour mon répertoire personnel ? .
Le bit setGID pour un répertoire
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.
Le bit sticky
Ce bit est représenté par un t (ou, beaucoup plus rarement, 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 le propriétaire du répertoire ou par le propriétaire du fichier ou par root.
Un 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 » de retrouver son fichier, d'où l'utilité de positionner le bit sticky pour ce répertoire. Les permissions de /tmp seront donc affichées ainsi dans la sortie de ls -ld :
drwxrwxrwt 6 root root 140 2008-03-01 06:07 /tmp/
Les permissions du répertoire /tmp autorisent tout utilisateur à y créer un fichier. Supposons que toto y crée un fichier modifiable en écriture par tout utilisateur :
-rw-rw-rw- 1 toto toto 0 2008-03-01 08:06 mon_fichier.txt
les permissions du fichier choin.txt autorisent, en principe, tout utilisateur à le supprimer (puisque les permissions des « autres utilisateurs » pour ce fichier comportent la permission d'écriture w). Toutefois, le bit sticky du répertoire /tmp garantit que seuls le propriétaire du fichier, toto, et le propriétaire de /tmp (qui est l'administrateur du système : root), seront en mesure de le supprimer. L'utilisateur glin, par exemple, ne pourra pas supprimer /tmp/choin.txt
Pour bien comprendre le rôle du bit sticky, notez que si le répertoire /tmp ne le possédait pas, s'il avait simplement les permissions :
drwxrwxrwx 6 root root 140 2008-03-01 06:07 /tmp/
alors, l'utilisateur glin pourrait parfaitement supprimer le fichier /tmp/choin.txt.
Pour la représentation du bit sticky dans le codage numérique des permissions, voir plus haut. Dans ce type de codage, le bit sticky a la valeur 1, valeur qui intervient dans le calcul du premier chiffre pour des permissions représentées sur 4 chiffres. Notez, à titre d'exemple, que le répertoire /tmp aurait les permissions : 1777. Un répertoire qui possèderait en outre le bit setGID, avec des permissions
rwxrwsrwt
aurait un codage numérique : 3777 (le 3 initial s'obtient ici en additionnant la valeur 2 du bit setGID (le s) à la valeur 1 du bit sticky).
Pour ajouter le bit sticky à un répertoire existant, on fait :
Cette permission particulière peut aussi être utile dans le cas d'un travail collaboratif. Dans le cadre d'un projet auquel participent plusieurs utilisateurs, on peut créer un répertoire du projet dont le propriétaire serait le responsable du projet et où tous les membres de l'équipe pourraient en toute sécurité créer des fichiers qui ne seraient supprimables que par l'administrateur système, le responsable du projet ou eux-mêmes. Noter que cela n'empêcherait pas chacun d'intervenir sur tout fichier qui aurait les permissions d'écriture appropriées, la modification du contenu d'un fichier par un tiers n'étant pas interdite par le bit sticky.
Exemple de permissions pour un répertoire de travail collaboratif
Bien qu'un répertoire de travail collaboratif fasse d'abord penser au monde de l'entreprise, cela fait sens d'envisager un tel répertoire dans l'univers associatif ou familial.
Créons un groupe d'utilisateurs pour le projet :
et ajoutons divers utilisateurs dans ce groupe avec l'outil graphique Mandriva drakuser invoqué ainsi en console :
Un répertoire pour le projet pourrait être créé ainsi :
drwxr-xr-x 2 root root 4096 2008-03-01 10:12 /home/projet1/
Donnons maintenant ce répertoire au chef de projet (toto) et au groupe du projet :
drwxr-xr-x 2 toto projet1 4096 2008-03-01 10:12 /home/projet1/
Changeons ses permissions. Le répertoire sera inaccessible aux utilisateurs non membres du projet. Il aura le bit setGID et le bit sticky.
drwxrws--T 2 toto projet1 4096 2008-03-01 10:12 /home/projet1/
(pour la raison d'être de la majuscule du bit sticky, voir la section suivante).
Désormais tout fichier créé dans /home/projet1/ appartiendra automatiquement au group projet1 (grâce à setGID) et un fichier de ce répertoire ne pourra être supprimé que par l'administrateur système (root), le chef du projet (toto) ou le propriétaire du fichier. Certains fichiers pourront être mis en lecture seule, d'autres être accessibles en écriture à tous les membres du groupe.
Permissions en majuscules ou en minuscules ?
Etant donné que dans la représentation usuelle les bits setUID, setGID ou 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é (-)
L'emploi de S ou T est relativement peu courant.
Pour un exemple voir #Exemple de permissions pour un répertoire de travail collaboratif.
Les permissions attribuées lors de la création d'un fichier : le masque de permissions ou umask
Qu'est-ce que l'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 et vous connaissez diverses techniques pour modifier ces permissions.
« 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, certainement déjà, que le créateur d'un fichier en devient d'emblée le propriétaire et que le groupe propriétaire du fichier sera alors le groupe principal (on dit aussi groupe primaire) 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.
Quel umask est actif sur mon système pour un utilisateur donné ?
Pour savoir quelles sont ces permissions pour un utilisateur donné, sur votre système actuel, vous pouvez vous connecter sous l'identité de cet utilisateur (qui peut être root ou un simple utilisateur) et lancer la commande :
umask -S
L'option -S provoque un affichage non numérique des permissions, 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 (en anglais o others) utilisateurs du système. Vous pourrez donc obtenir quelque chose comme cela :
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 :
0022
hum… bizarre… bizarre.
Le premier chiffre, le zéro initial, reste normalement inchangé.
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 r-x.
Nous retrouvons donc bien les mêmes résultats qu'avec l'option umask -S - même si c'est de façon passablement tortueuse.
Nous disposons finalement de deux façons de déterminer les permissions par défaut pour un utilisateur, lancer umask -S ou lancer umask sans option.
Pour trouver les valeurs de l'umask sur votre système, vous pouvez aussi utiliser l'interface graphique en faisant : Menu > Outils > Outils système > > Configurer votre ordinateur > Sécurité > Configurer le niveau de sécurité du système > Options système > Masque de permissions. En face des deux rubriques concernant les Masques de permissions, vous trouverez sans doute Choix par défaut. Pour savoir à quoi correspond ce choix par défaut, cliquez sur le bouton Aide (en bas de la fenêtre) et faites défiler jusqu'aux items correspondant aux masques de permission.
Comment changer l'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 :
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 de façon permanente 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.
umask et bit d'exécution
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 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.
umask et chmod
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 :
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 :
-r-xr-xr-x
et si votre umask est u=rwx,g=rx,o=rx.
u=rwx,g=rx,o=rx
Les permissions de choin après exécution de chmod deviendront ceci :
-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 :
-rwxrwxrwx
umask et gestion de la sécurité
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). Voir là-dessus : msec.
Quelles permissions pour mon répertoire personnel ?
Sous Mandriva, les permissions de votre dossier personnel (autrement dit, le dossier /home/toto, si votre nom d'utilisateur est toto) sont déterminées d'abord par le niveau de sécurité que msec attribue à votre système.
Changer le niveau de sécurité peut donc entrainer une modification de ces permissions.
Il est cependant tout à fait possible aussi de modifier durablement les permissions de ce répertoire sans avoir à changer de niveau de sécurité.
Mais, au fond, pourquoi changer ? Quelles sont les conséquences de l'attribution de telles ou telles permissions à mon répertoire personnel ?
Cette section va revenir en détail sur tous ces points.
Les permissions par niveau de sécurité
Il y a quelque temps le module de gestion de la sécurité de Mandriva, msec, attribuait des permissions aux répertoires personnels comme indiqué dans le tableau suivant. Le système des niveaux de msec a un peu changé, mais cela vous donne encore une idée des possibilités qui s'offrent à vous :
| Très faible (niveau 1) et Standard (niveau 2) | 755 | rwxr-xr-x |
| Elevé (niveau 3) | 711 | rwx--x--x |
| Plus élevé (niveau 4) et Paranoïaque (niveau 5) | 700 | rwx------ |
La parfaite sécurité : 700
Si vous êtes certain de ne jamais vouloir que les autres utilisateurs de votre système mettent le nez dans votre répertoire personnel pour y lire, modifier, créer ou supprimer des données, ou exécuter des programmes, alors il vous faut donner à celui-ci des permissions de ce type : rwx------ Dans ce cas, seul le propriétaire du répertoire (vous-même) a des droits de lecture, écriture et exécution. De telles permissions vous protègeront aussi de manœuvres d'éventuels intrus malveillants qui auraient réussi une percée jusqu'à votre système via Internet ou un réseau plus petit.
Dans le codage numérique des permissions utilisé par chmod, cela veut dire que votre répertoire aura les permissions 700.
Nota Bene : nous verrons plus bas que même avec ces permissions, il vous sera cependant possible de rendre accessibles certaines parties de votre répertoire si vous le décidez.
Permettre un accès limité : 711
Vous pouvez aussi souhaiter permettre aux autres utilisateurs un accès quelque peu limité à votre propre répertoire.
C'est ce qui se passera si vous accordez à votre répertoire personnel /home/toto les permissions : rwx--x--x autrement dit les permissions 711 du codage numérique des permissions.
Que permettent et qu'interdisent ces permissions ?
Tout d'abord, elle ne permettent à personne d'autre que vous d'afficher la liste des fichiers et répertoires qui se trouvent à la racine de votre répertoire personnel (sont dits « à la racine » de votre répertoire personnel les fichiers ou répertoires qui ne sont pas inclus eux-mêmes dans un sous-répertoire de votre répertoire personnel). Ainsi, un essai de commande ls -l /home/toto n'affichera rien d'autre qu'un message d'erreur, s'il est lancé par un utilisateur autre que vous : on ne peut donc en aucun cas « voir » le contenu de la racine de votre répertoire (mais vous, vous le pouvez, bien entendu).
Et si, d'aventure, un autre utilisateur avait appris ou deviné l'existence d'un certain fichier ou d'un certain sous-répertoire qui serait situé à la racine de votre répertoire personnel, cet utilisateur ne pourrait en aucun cas les supprimer ou les renommer (il ne pourrait pas, par exemple, supprimer ou renommer le fichier /home/toto/choin.txt ou le répertoire /home/toto/choin/). Toutes ses tentatives en ce sens échoueraient. Il ne pourrait pas non plus créer un nouveau fichier à la racine de votre répertoire personnel (comme /home/toto/notule), ou un nouveau sous-répertoire (comme /home/toto/docs/). Bref, l'inventaire de tout ce qui se trouve à la racine de votre propre répertoire ne pourra pas être modifié par un autre utilisateur.
Comme vous le voyez la « racine » de votre répertoire personnel bénéficierait d'une certaine protection...
Toutefois, attention, attention :
- avec ces permissions, tout le reste de votre répertoire l'est sensiblement moins ! En effet, un simple utilisateur quelconque pourra parfaitement
- pénétrer dans n'importe quel sous-répertoire de votre dossier personnel (pour peu qu'il en connaisse ou devine l'existence et que ce sous-répertoire possède des permissions d'exécution pour les « autres utilisateurs » ce qui est généralement le cas par défaut pour les répertoires)
- il pourra afficher le contenu de ce répertoire (eh oui ! seul le répertoire personnel est protégé des regards indiscrets... mais pas ses sous-répertoires du moins pour qui saura deviner leur existence...)
- il pourra aussi afficher le contenu des fichiers ainsi découverts, si ces fichiers ont des permissions de lecture appropriées (ce qui est très souvent le cas par défaut)
- et même, plus rarement il est vrai, il pourra effectuer diverses modifications du contenu des fichiers ou lancer des fichiers exécutables, s'il y en a etc. : tout dépendra alors des permissions des fichiers en question.
- Tout ce qui précède vaudra aussi pour les fichiers situés à la racine du répertoire personnel.
Ces permissions sont donc quelque peu trompeuses : elles peuvent dissuader un simple curieux, compliquer assurément la tâche d'un intrus malveillant, mais elles ne constituent pas à elles seules une véritable protection systématique de l'ensemble de votre répertoire personnel. En particulier, les permissions de lecture aux « autres utilisateurs » étant le plus souvent octroyées par défaut à de nombreux types de fichiers, la confidentialité des données risquera de ne pas être strictement assurée. Si vous avez donné les permissions 711 à votre répertoire personnel, pensez au moins à attribuer à tout sous-répertoire destiné à contenir des données confidentielles un nom bien long et bien improbable, aussi difficile à deviner que possible...
D'un autre côté, avec de telles permissions, il est relativement facile de permettre à un autre utilisateur de consulter un certain répertoire (dont on lui indiquera le chemin), voire de lui permettre d'y travailler en ajustant en conséquence dans ce dernier cas les permissions du répertoire (pour qu'il puisse par exemple y créer ou y supprimer des fichiers) ou en ajustant les permissions des fichiers qu'il contient de façon à les lui rendre accessibles en écriture.
Entr'ouvrir la porte : 755
Lorsque les permissions 755 sont attribuées au répertoire personnel, la seule chose que ces permissions interdisent à un autre utilisateur est de modifier l'inventaire des fichiers et répertoires situés à la racine de votre répertoire : il ne pourra ni en créer ni en supprimer.
En dehors de cela, ces permissions ne lui interdiront rien par elles-mêmes : il pourra afficher le contenu du répertoire, y naviguer et y travailler. La seule véritable protection, dans ce cas, sera due aux permissions des fichiers et sous-répertoires que contient votre répertoire personnel. Notez que les différents sous-répertoires n'ayant pas, en général, par défaut, la permission d'écriture pour les autres utilisateurs, créer ou supprimer des fichiers dans l'ensemble du répertoire personnel lui sera probablement largement impossible. Les permissions par défaut n'attribuant généralement pas non plus aux fichiers les permissions d'écriture aux autres utilisateurs, il ne pourra pas non plus, dans la plupart des cas, modifier le contenu d'un fichier. A vous, en tout cas, d'être vigilant et de ne pas attribuer des permissions trop larges à tort et à travers...
Avec les permissions 755 associées à votre répertoire personnel, la collaboration avec d'autres utilisateurs est plus aisée, mais vos données et vos programmes sont plus vulnérables et surtout moins protégés des regards indiscrets.
Comment attribuer les permissions de votre choix au répertoire personnel
La meilleure façon de procéder est probablement de créer une règle drakperm, en suivant les indications données dans cette section.
Permettre l'utilisation de certaines de vos ressources même avec un répertoire personnel très protégé
Un répertoire personnel avec les permissions 700 est bien protégé, mais il empêche tout autre utilisateur que son propriétaire de consulter ou modifier un quelconque contenu de ce répertoire.
Une possibilité de circonvenir ce problème pourrait être de créer sous /home un répertoire dédié, par exemple /home/partage, doté de permissions d'exécution qui autoriseront les autres utilisateurs ou un certain groupe d'utilisateurs à y pénétrer. Ensuite, vous pourrez créer des liens en dur vers les fichiers de votre répertoire personnel dont vous souhaitez qu'ils puissent être consultés, voire modifiés par ces utilisateurs. Bien sûr, il faudra donner aussi à ces fichiers les permissions appropriées.
Les listes de contrôle d'accès (ACL)
Le système de permissions qui a été décrit dans les pages précédentes offre de nombreuses possibilités et suffit le plus souvent. Toutefois, dans certaines situations, il peut ne pas répondre encore exactement à ce que l'on souhaiterait. Par exemple, dans un environnement de travail en commun évolutif, à un moment donné de l'évolution d'un projet, vous pourriez avoir envie de donner à une personne particulière, ou à un ensemble de personnes, des droits spécifiques sur un fichier donné, sans pour autant modifier l'architecture d'ensemble des permissions et des propriétés, ni changer le propriétaire et le groupe propriétaire du fichier : c'est là typiquement ce qui est rendu possible par une Liste de Contrôle d'Accès (ou ACL, de l'anglais Access Control List). Pour plus de détails sur les ACL vous pourrez consulter :
Access Control List
(en français)
Comment fonctionnent les ACL Posix sous Linux
Vous pourrez lire aussi un article de GNU/Linux Magazine France, n° 79, janvier 2006.
Voir aussi les deux sections suivantes.
Les attributs étendus d'un fichier
Les ACL reposent sur l'association d'attributs étendus à des fichiers, attributs grâce auxquels l'utilisateur peut consigner des « méta-données » très diverses concernant le fichier. Sur ces attributs étendus on pourra lire l'article de GNU/Linux Magazine France mentionné au paragraphe précédent.
Une utilisation particulière des attributs étendus avec les systèmes de fichiers ext2, ext3 et sous certaines conditions reiserfs, est possible avec la commande chattr qui peut associer à un fichier quelques attributs intéressants préconfigurés.
Rendre des fichiers ineffaçables et immodifiables même par root
Un exemple d'emploi typique : vous stockez sur votre disque des fichiers d'archives qui n'ont vocation qu'à être consultés mais jamais ou très rarement modifiés ? Alors, pour éviter tout incident dû à la maladresse ou à la malveillance, vous les rendrez non modifiables et surtout non effaçables (même par root) à l'aide de la commande
Naturellement, root, et lui seul, pourra annuler l'attribut par un simple :
(rappelez-vous que même un fichier sans droit d'écriture peut être effacé par son propriétaire et par root, c'est ce qu'empêche justement l'attribut +i). La commande peut agir récursivement sur tout un répertoire avec l'option -R.
