Permissions

Un article de Wiki de la communauté Mandriva.

---

CETTE PAGE EST UNE VERSION RÉVISÉE ET MISE À JOUR DE CINQ PAGES MAINTENANT OBSOLÈTES DE L'ANCIENNE BASE DE CONNAISSANCES,DONT LA PREMIÈRE EST À L'ADRESSE :
http://club.mandriva.com/xwiki/bin/view/KB/BasicsBpermis ptyxs 1 mars 2008 à 12:16 (CET)

---

Sommaire 1 Introduction 1.1 La notion de permission 1.2 Pourquoi il est important de comprendre les permissions 2 Quelques exemples concrets 2.1 L'exemple de locate 2.1.1 Les fichiers : l'exemple de l'exécutable updatedb 2.1.2 Les répertoires : l'exemple de /var/lib/mlocate 3 setUID, setGID 3.1 setGID : l'exemple de l'exécutable locate 3.2 setUID : l'exemple de Xwrapper 4 Comment modifier les permissions en console 4.1 Changer de propriétaire à l'aide de chown et chgrp 4.2 Modifier les propriétés d'accessibilité à l'aide de chmod 4.2.1 Utiliser chmod avec des lettres 4.2.2 Utiliser chmod avec des valeurs numériques 4.2.3 Comparaison des deux méthodes 5 Un cafouillage courant : supprimer récursivement la permission d'exécution 6 Changer les permissions par l'interface graphique 6.1 Sous KDE 6.1.1 Changer les permissions 6.1.2 Changer le propriétaire ou le groupe 6.2 Imposer des permissions à certains répertoires avec drakperm 6.3 Introduction 6.3.1 Créer des règles 6.3.2 Relations entre règles 7 Complément sur les permissions pour un répertoire 7.1 Les permissions 'normales' 7.1.1 La permission r pour un répertoire 7.1.2 La permission w pour un répertoire 7.1.3 La permission x pour un répertoire 7.2 Le bit setGID pour un répertoire 7.3 Le bit sticky 7.4 Exemple de permissions pour un répertoire de travail collaboratif 8 Permissions en majuscules ou en minuscules ? 9 Les permissions attribuées lors de la création d'un fichier : le masque de permissions ou umask 9.1 Qu'est-ce que l'umask ? 9.2 Quel umask est actif sur mon système pour un utilisateur donné ? 9.3 Comment changer l'umask 9.4 umask et bit d'exécution 9.5 umask et chmod 9.6 umask et gestion de la sécurité 10 Quelles permissions pour mon répertoire personnel ? 10.1 Les permissions par niveau de sécurité 10.1.1 La parfaite sécurité : 700 10.1.2 Permettre un accès limité : 711 10.1.3 Entr'ouvrir la porte : 755 10.2 Comment attribuer les permissions de votre choix au répertoire personnel 11 Permettre l'utilisation de certaines de vos ressources même avec un répertoire personnel très protégé 12 Les listes de contrôle d'accès (ACL) 12.1 Les attributs étendus d'un fichier 12.2 Rendre des fichiers ineffaçables et immodifiables même par root

[modifier] Introduction

[modifier] 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)).

Cela donnera, par exemple, quelque chose qui pourra ressembler à cela :

Plus concrètement, pour le fichier choin.txt, appartenant à l'utilisateur toto et au groupe de toto, cela pourra donner :

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 :

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à).

[modifier] 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 :

(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...

[modifier] 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 ».

[modifier] 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 :

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.

[modifier] 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 :

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...

[modifier] 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 :

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 :

(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 :

(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: :

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 ?.

[modifier] setUID, setGID

[modifier] 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 :

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 :

(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:

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.

[modifier] 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 :

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.

[modifier] 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.

[modifier] 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.

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] Modifier les propriétés d'accessibilité à l'aide de chmod

chmod est d'un maniement un peu plus délicat.

[modifier] 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 :

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.

[modifier] 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 », 2 signifie « écriture » et 1 « exécution ».

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 :

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 :

et :

attribuerait le bit setGID ce qui donnerait :

Le répertoire /tmp, qui possède traditionnellement les permissions rwxrwxrwt (avec t pour le bit sticky), aurait les permissions 1777, soit :

Vous suivez ?

[modifier] 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 :

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 :

Avec la seconde méthode si par exemple nous faisons :

nous obtenons bien sûr :

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-----.

[modifier] 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.

[modifier] 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.

[modifier] Sous KDE

[modifier] 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.

[modifier] 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...

[modifier] Imposer des permissions à certains répertoires avec drakperm

[modifier] Introduction

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.

[modifier] Créer des règles

Voici comment créer des règles de ce genre.

• Pour accéder à l'interface
  • Menu > Outils > Outils système > Configurer votre ordinateur > Sécurité > Ajuster finement les permissions du système
• ou bien :
  • Ouvrir une console graphique (Konsole, rXVT...), passer sous root, puis taper drakperm et pressez la touche ENTREE.

Vous arrivez à une fenêtre qui vous montre quelles permissions et propriétaires sont imposés par le niveau de sécurité du système actuellement activé. Examinez-les.

Prenons un exemple.

Supposons encore que vous teniez à ce que votre courrier personnel et tout ce qui le concerne soit entièrement inaccessible à tous les autres utilisateurs de votre système. Si vous utilisez le courielleur Mozilla Thunderbird tout cela se trouve dans le fichier caché /home/<votre_nom_d_utilisateur>/.thunderbird.
Comment assurer à ce dossier une protection spécifique permanente ? Très simple.

• 1. Choisissez Réglages personnalisés et système.
• 2. Cliquez en bas sur Ajouter une règle.
• 3. Pressez le bouton Naviguer, et naviguez jusqu'au répertoire qui vous intéresse, en l'occurrence, dans notre exemple, /home/toto/.thunderbird, jusqu'à ce que son chemin soit affiché dans la rubrique Sélection, puis cliquez sur Valider.
• 4. Faites vos choix dans la fenêtre qui s'affiche. Cliquez sur OK. Cliquez encore sur OK dans la fenêtre Permissions. Enfin, quittez le Centre de Contrôle Mandriva.

Et voilà, c'est fait...

Nous avons donné ici un exemple de permission pour un répertoire, mais vous pouvez aussi imposer de la même façon des permissions à un ou plusieurs fichiers, comme on en verra un exemple dans la section suivante.

[modifier] Relations entre règles

Lorsque vous créez plusieurs règles personnalisées, certaines peuvent interférer. Dans ce cas, il faut savoir que les règles sont appliquées dans l'ordre de leur affichage de haut en bas. Il est possible de modifier cet ordre en sélectionnant une règle (d'un clic) et en usant du bouton Descendre ou du bouton Monter, affichés en bas de la fenêtre.

Le principe à suivre est : une règle « générale » doit précéder une règle qui définit un cas particulier ou une exception.

Un exemple pourra être approprié pour faire comprendre tout cela.

Supposons que, dans le dossier /home/toto/Documents/Notes, vous souhaitiez permettre aux membres de votre groupe de lire tous les fichiers /home/toto/Doucments/Notes/Perso* (ceux dont le nom commence par Perso), sauf pour le fichier /home/toto/Documents/Notes/Perso3 qui doit, lui, rester non lisible.

Dans ce cas, vous commencez par créer une règle générale qui rendra accessibles en lecture tous les fichiers /home/toto/Documents/Notes/Perso*.

Puis, vous faites une seconde règle (qui devra impérativement suivre la précédente à l'affichage), pour traiter le cas particulier du fichier /home/toto/Documents/Notes/Perso3 règle qui interdira la lecture de ce fichier.

Ainsi, la première règle donnera la propriété de Lecture au Groupe pour tous les fichiers du répertoire concerné dont les noms commencent par Perso - disons, par exemple : Perso1, Perso2, Perso3, Perso4 - puis la règle suivante retirera cette propriété au seul fichier Perso3.

Bien sûr, si les règles étaient affichées à l'inverse et donc exécutées aussi dans l'ordre inverse, le résultat serait que Perso3 serait finalement lisible par les membres du groupe, comme tous les autres fichiers commençant par Perso ! Attention donc à bien ordonner vos règles dans des cas de ce genre : une règle « générale » doit précéder une règle qui définit un cas particulier ou une exception.

Pour ceux qui aiment mettre les mains sous le capot, sachez que les règles personnalisées créées par drakperm sont « entreposées » dans le fichier /etc/security/msec/perm.local qu'il est aussi possible de modifier à la main, sous root.

[modifier] Complément sur les permissions pour un répertoire

[modifier] 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.

[modifier] 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. :

(l'option -p permet de créer en une fois les deux répertoires).

Les permissions - normales - de doc/ sont :

Je peux afficher le contenu de doc/ et de son sous-répertoire :

Maintenant, je modifie les permissions de doc/ :

Et j'essaie de regarder :

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 :

Et je ne pourrai pas même lire le contenu du fichier doc/liste.txt (pour cela aussi il faudrait à doc/ la permission x) :

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/.

---

---

[modifier] 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 :

Modifions ses permissions :

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/ !!

[modifier] 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 ? .

[modifier] 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étai