Adaptation française : Philippe Pétrinko
Relecture de la version française: Deny
Copyright © 2008 Joey Prestia
Copyright © 2008 Philippe Petrinko
Copyright © 2008 Deny
Article paru dans le n°152 de la Gazette Linux de juillet 2008.
Article publié sous Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.
Table des matières
Linux a la capacité d'utiliser les ACL (Access Control List, listes de Contrôle d'Accès) au niveau de chaque fichier. Ceci permet aux utilisateurs et aux administrateurs de définir les personnes y ayant accès, ainsi que leur niveau d'accès, au-delà des accès basiques gérés par le système de fichiers sous forme des droits.
Imaginons une société possédant une équipe d'employés travaillant sur un projet. Chaque employé, selon son rôle et son degré de responsabilité, requiert un ensemble particulier de droits; ceci peut être mis en oeuvre via les ACL. Un terme plus approprié serait discretionary ACL (LCA discrétionnaire). Au cas où des documents seraient classés confidentiels pour certains mais pas pour tous, ces ACL facilitent la tâche dans la mesure où la sécurité peut être gérée sans impliquer plus de personnes que celles directement concernées.
Les ACL sont disponibles pour le système de fichiers ext3. Par défaut, Red Hat Enterprise Linux 5© inclut la fonction des ACL pour toutes les partitions ext3 lors de l'installation. Ceci signifie que si vous créez une nouvelle partition après installation et que vous essayez d'utiliser les ACL dessus, vous échouerez: Vous devrez pour cela ajouter l'option de montage pour les ACL dans le fichier /etc/fstab
pour vous assurer de la disponibilité des ACL.
La plupart des commandes prennent en charge les listes d'ACL, à l'exception de certaines; en cas de doute, veuillez vous en assurer en consultant les pages man. La commande tar, par exemple, est une de ces exceptions.
Parcourons la mise en place et l'utilisation des ACL afin d'évaluer la finesse du contrôle permis par les ACL. Puisque je dispose d'espace non partitionné sur ce disque, je vais suivre la procédure de mise en place des ACL sur une nouvelle partition:
[root@localhost ~]# fdisk /dev/hda [root@localhost ~]# partprobe [root@localhost ~]# mkfs.ext3 -L /srv/data /dev/hda10
Ensuite, je dois éditer le fichier /etc/fstab
et ajouter la nouvelle partition avec les options de montage pour les ACL.
[root@localhost ~]# vi /etc/fstab LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext2 defaults 1 2 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 LABEL=/home /home ext3 usrquota,grpquota 1 2 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 LABEL=/tmp /tmp ext3 defaults 1 2 LABEL=/usr /usr ext3 defaults 1 2 LABEL=/var /var ext3 defaults 1 2 LABEL=SWAP-hda3 swap swap defaults 0 0 LABEL=/srv/data /srv/data ext3 defaults,ACL 1 1
Après cela, je vais créer un répertoire et monter notre nouvelle partition.
[root@localhost ~]# mkdir /srv/data [root@localhost ~]# mount -a
Maintenant, je vais ajouter un groupe nommé « programmeurs », et créer plusieurs comptes d'utilisateur y appartenant: « chefdeprojet », « prog1 », « prog2 » et « tech ». Je dois aussi modifier les droits d'accès et le propriétaire de manière appropriée au nouveau groupe. Ainsi, les fichiers créés dans ce répertoire appartiendront au groupe « programmeurs ».
[root@localhost ~]# groupadd programmeurs [root@localhost ~]# chown .programmeurs /srv/data [root@localhost ~]# chmod 2770 /srv/data [root@localhost ~]# useradd chefdeprojet -G programmeurs [root@localhost ~]# passwd chefdeprojet [root@localhost ~]# useradd prog1 -G programmeurs [root@localhost ~]# passwd prog1 [root@localhost ~]# useradd prog2 -G programmeurs [root@localhost ~]# passwd prog2 [root@localhost ~]# useradd tech -G programmeurs [root@localhost ~]# passwd tech [root@localhost ~]# cd /srv/data [root@localhost data]# ls lost+found [root@localhost data]# su chefdeprojet [chefdeprojet@localhost data]$ [chefdeprojet@localhost data]$ touch projet [chefdeprojet@localhost data]$ chmod 700 projet
A ce stade, « chefdeprojet » a créé un fichier projet et en a restreint l'accès via le système de fichiers.
La commande getfacl affiche les informations des ACL et les droits pour un fichier ou un répertoire donné:
[chefdeprojet@localhost data]$ getfacl projet # file: projet # owner: chefdeprojet # group: programmeurs user::rwx group::--- other::---
Cette commande met à jour les ACL. Il y a trois champs à connaître pour la ligne de commande:
Identifiant:utilisateur/groupe:droits
L'identifiant peut être ainsi exprimé:
u - Affectera les droits d'accès de l'utilisateur donné |
g - Affectera les droits d'accès du groupe donné |
o - Affectera les droits d'accès de tous les autres |
m - Affectera le masque des droits effectifs |
Utilisateur/groupe est le nom d'utilisateur ou de groupe concerné, qui peut aussi être exprimé par un UID ou un GID
Les droits sont:
r or 6 - accès en lecture |
w or 4 - accès en écriture |
x or 1 - droit d'exécution |
- or 0 - aucun droit |
Les droits peuvent bien entendu être combinés, comme pour r-x ou 5 selon ce que vous souhaitez. L'utilisation la plus simple de la commande ressemble à ceci:
setfacl [options] identifiant:utilisateur/groupe:droits
nom de fichier
[chefdeprojet@localhost data]$ setfacl -m u:prog1:rwx projet [chefdeprojet@localhost data]$ setfacl -m u:prog2:rw- projet [chefdeprojet@localhost data]$ getfacl projet # file: projet # owner: chefdeprojet # group: programmeurs user::rwx user:prog1:rwx user:prog2:rw- group::--- mask::rwx other::---
A ce stade, nous avons augmenté les droits de nos programmeurs: « prog1 » peut maintenant lire, écrire, et exécuter et « prog2 » a accès en lecture et en écriture. Vous remarquerez que la sortie de getfacl comporte maintenant un champ « mask » à la fin: Le masque est un maximum de niveau d'accès et peut être utilisé pour restreindre immédiatement les droits sur ce fichier. De plus, si vous faîtes un ls -l, la liste affichera un +
à la fin des droits de chaque fichier dont les ACL ont été définis
[chefdeprojet@localhost data]$ ls -l total 13 drwx------ 2 root programmeurs 12288 Mar 19 21:59 lost+found -rwxrw----+ 1 chefdeprojet programmeurs 0 Mar 22 20:30 projet [chefdeprojet@localhost data]$
Le groupe « programmeurs » a besoin de l'accès en lecture sur ce fichier, car les autres programmeurs auront besoin de voir le contenu du document. Si nous ne précisons pas le groupe explicitement lors de l'exécution de la commande setfacl, il est sous-entendu comme vous pouvez le constater ci-dessous:
[chefdeprojet@localhost data]$ setfacl -m g::r projet [chefdeprojet@localhost data]$ getfacl projet # file: projet # owner: chefdeprojet # group: programmeurs user::rwx user:prog1:rwx user:prog2:rw- group::r-- mask::rwx other::---
En modifiant le masque, je peux changer les droits actuels effectifs pour le niveau le plus restrictif tel que défini par le masque et obtenir qu'ils deviennent les droits effectifs. Même si un utilisateur ou un groupe a des droits qui dépassent ceux du masque effectif, le masque restreindra leurs droits effectifs.
[chefdeprojet@localhost data]$ setfacl -m mask::r projet [chefdeprojet@localhost data]$ getfacl projet # file: projet # owner: chefdeprojet # group: programmeurs user::rwx user:prog1:rwx #effective:r-- user:prog2:rw- #effective:r-- group::r-- mask::r-- other::---
Si nous voulons retirer un de nos programmeurs—par exemple « prog1 »— d'une ACL pour ce projet et que ses droits redeviennent ceux du groupe, cela serait fait ainsi:
[chefdeprojet@localhost data]$ setfacl -x u:prog1: projet [chefdeprojet@localhost data]$ getfacl projet # file: projet # owner: chefdeprojet # group: programmeurs user::rwx user:prog2:rw- group::r-- mask::rw- other::---
L'option -x
retire l'utilisateur précisé, ou le groupe, ou tous les autres, de l'ACL associée—Ainsi, « prog1 » n'a maintenant plus que l'accès au niveau du groupe (et sans doute une réduction de salaire pour accompagner le tout).
Et si nous voulions enregistrer nos attributs d'ACL dans un fichier contenant la ligne u:prog1:rwx
? Nous pourrions utiliser l'option -M
pour transmettre les attributs à un nouveau fichier.
[chefdeprojet@localhost data]$ touch file [chefdeprojet@localhost data]$ echo "u:prog1:rwx" > ACL [chefdeprojet@localhost data]$ setfacl -M ACL file [chefdeprojet@localhost data]$ getfacl file # file: file # owner: chefdeprojet # group: programmeurs user::rw- user:prog1:rwx group::rw- mask::rwx other::r--
Nous avons transmis avec succès les attributs d'ACL du fichier acl
vers le fichier vide file
. Avez-vous remarqué que le masque des droits effectifs est passé de « rw- » à « rwx » ? Si vous n'aviez pas souhaité que le masque des droits effectifs change lorsque vous avez modifié les droits, vous auriez pu utiliser l'option -n
en plus de vos autres options afin de l'empêcher.
Pour copier les ACL d'un fichier à un autre, vous exécuterez getfacl fichier_avec.ACL | setfacl -b -n -M - fichier_ayant_besoin.acl comme je le montre ci-dessous. Le dernier « - » est important; il indique à setfacl de lire les données de l'entrée standard, qui est fournie par le canal de communication précédent.
[chefdeprojet@localhost data]$ getfacl fichier_avec.ACL # file: fichier_avec.ACL # owner: chefdeprojet # group: programmeurs user::rw- user:prog1:rwx group::rw- mask::rwx other::r-- [chefdeprojet@localhost data]$ touch fichier_ayant_besoin.ACL [chefdeprojet@localhost data]$ getfacl fichier_avec.ACL | setfacl -b -n -M - fichier_ayant_besoin.ACL [chefdeprojet@localhost data]$ getfacl fichier_ayant_besoin.ACL # file: fichier_ayant_besoin.ACL # owner: chefdeprojet # group: programmeurs user::rw- user:prog1:rwx group::rw- mask::rwx other::r--
Les répertoires peuvent avoir une ACL par défaut, qui définit les droits d'accès dont les fichiers contenus hériteront lors de leur création. Une ACL par défaut a un effet sur les sous-répertoires comme sur les fichiers. D'abord, établissons un répertoire ayant des droits par défaut. Les droits par défauts sont créés en utilisant l'option -d
en modifiant le répertoire.
[chefdeprojet@localhost data]$ mkdir travail [chefdeprojet@localhost data]$ setfacl -d -m g::r-x travail/ [chefdeprojet@localhost data]$ getfacl travail/ # file: travail # owner: chefdeprojet # group: programmeurs user::rwx group::rwx other::r-x default:user::rwx default:group::r-x default:other::r-x
Observez ce qui suit lorsque je crée un répertoire fils, travail/semaine1
. Remarquez que semaine1
héritera des droits de l'ACL par défaut du répertoire parent travail
:
[chefdeprojet@localhost data]$ mkdir travail/semaine1 [chefdeprojet@localhost data]$ getfacl travail/semaine1/ # file: travail/semaine1 # owner: chefdeprojet # group: programmeurs user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x
Enfin, voyons comment ces valeurs par défaut se propagent à un simple fichier créé dans le répertoire "travail/semaine1". Je vais montrer en premier ACL du parent, puis créer le fichier:
[chefdeprojet@localhost data]$ getfacl travail/semaine1/ # file: travail/semaine1 # owner: chefdeprojet # group: programmeurs user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x [chefdeprojet@localhost data]$ touch travail/semaine1/jour1 [chefdeprojet@localhost data]$ getfacl travail/semaine1/jour1 # file: travail/semaine1/jour1 # owner: chefdeprojet # group: programmeurs user::rw- group::r-- other::r-- [chefdeprojet@localhost data]$ umask 0002
Remarquez que le fichier a été créé avec un masque actif de 0002. Ceci signifie que le fichier aurait dû avoir des droits de 664; Au lieu de cela, il a été créé avec les droits 644 à cause de l'ACL par défaut du répertoire et de l'héritage de l'ACL du répertoire parent.
Ceci n'est pas la liste exhaustive des possibilités; cependant, ces quelques notions de base devraient être suffisantes pour vous permettre de commencer à utiliser les ACL. Les ACL peuvent être utilisées pour ajuster les droits dans les cas particuliers où les droits habituels de Linux
ne feront pas l'affaire; Elles peuvent aussi alléger la surcharge administrative lorsque les chefs de projets apprennent à les utiliser de manière correcte et efficace. De plus, les ACL peuvent être un outil précieux dans la boite à outils de chaque administrateur pour aider à ajuster la sécurité.
* POSIX Access Control Lists on Linux |
* SUSE Linux Administration Guide |
* Michael Jang's book "Red Hat Certified Engineer Linux Study Guide", 5th Edition |
* Mark G. Sobell's book "A Practical Guide to Red Hat Linux", 3rd Edition |
Joey est né à Phoenix et a commencé à programmer à l'âge de quatorze ans sur un Timex Sinclair 1000©. Il espérait pouvoir tirer quelque chose de ce modèle d'ordinateur ancien. Maîtrisant rapidement le BASIC et l'Assembleur, Joey est devenu programmeur en 1990 et a ajouté le COBOL, le Fortran et le Pascal à son répertoire de langages de programmation. Depuis lors, il se passionne pour presque tous les aspects de l'informatique. Il s'est perfectionné et a découvert RedHat Linux© en 2002, quand on lui a donné une version six de RedHat©. Ce fut le début d'une nouvelle passion centrée sur
Linux
. Actuellement, Joey termine sa formation en gestion de réseau sousLinux
et travaille sur le campus pour la RedHat Academy de l'université, en Arizona. Il fait aussi partie de l'équipe de la Linux Gazette comme coordinateur de miroir.
L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.
Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://wiki.traduc.org/Gazette_Linux.
Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.