Les notes de Joey : Les Listes de Contrôle d'accès

Gazette Linux n°152 - Juillet 2008

Adaptation française : Philippe Pétrinko

Relecture de la version française: 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

introduction
Définir une partition pour les ACL
Utiliser getfacl
Utiliser setfacl
Créer des ACL
Restreindre les droits effectifs
Retirer un utilisateur d'une ACL
Transférer des attributs d'ACL à partir d'un fichier de spécification
Copier les ACL d'un fichier à un autre
Pour un répertoire, hériter l'ACL par défaut du répertoire parent
Pour un fichier, hériter de l'ACL par défaut du répertoire parent
Fin

introduction

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.

Définir une partition pour les ACL

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.

Utiliser getfacl

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

Utiliser setfacl

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

Créer des ACL

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

Restreindre les droits effectifs

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

Retirer un utilisateur d'une ACL

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

Transférer des attributs d'ACL à partir d'un fichier de spécification

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.

Copier les ACL d'un fichier à un autre

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

Pour un répertoire, hériter l'ACL par défaut du répertoire parent

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

Pour un fichier, hériter de l'ACL par défaut du répertoire parent

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

Fin

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

Adaptation française de la Gazette Linux

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.