ACL Linux. Que sont les ACL Linux et à quoi servent-elles ?

Les listes de contrôle d'accès Linux, ou ACL, peuvent prendre un certain temps pour s'y habituer, mais sont inestimables pour obtenir un contrôle plus granulaire des autorisations du système de fichiers Linux.

Parmi les défis de l'administration de Linux dans l'environnement d'entreprise moderne, il y a l'attente que nous puissions et devrions gérer qui a accès à quelles informations. Il était une fois, les seules personnes qui avaient besoin d'accéder aux systèmes de fichiers Linux pouvaient être classées de manière générale : via les autorisations du système de fichiers Linux.

L'acronyme «ACL» signifie Liste de contrôle d'accès et renvoie ici à une extension de la gestion des permissions, au-delà de la tradition des systèmes Unix.

Comme c'est souvent le cas, les noms représentant des acronymes peuvent signifier différentes choses dans différents contextes. Dans le cas particulier de l'acronyme ACL, celui-ci est également utilisé dans d'autres situations, notamment dans la gestion de l'accès aux services HTTP, où l'on souhaite réguler l'accès au service ou à des ressources particulières. Ce qu'il faut comprendre, c'est que l'acronyme ACL, même si, en tant qu'acronyme, fait référence aux mêmes mots, représente des situations différentes selon le contexte.

POSIX a produit quelques projets sur la possibilité d'étendre la gestion des permissions des systèmes Unix (POSIX 1003.1ee POSIX 1003.2c), mais ces travaux sont restés inachevés. Ces brouillons sont publics et plusieurs systèmes Unix proposent certaines de ces extensions. Les extensions référencées avec l'acronyme ACL, ou éventuellement avec "ACL POSIX" (bien qu'elles ne soient que des brouillons), ne sont qu'une partie de l'ensemble global et dans ce chapitre nous voulons décrire en particulier l'implémentation relative aux systèmes GNU/ Linux.

 

Revoir les bases

Le système de fichiers Linux nous offre trois types de permissions. Voici une revue simplifiée :

• U ser (ou utilisateur propriétaire)
• G groupe (ou groupe propriétaire)
• Autre (tous les autres)

 

Avec ces autorisations, nous pouvons accorder trois (en fait cinq, mais nous y reviendrons dans une minute) types d'accès :

• Lisez _
• Écrire _
• e X exécuter

Ces niveaux d'accès sont souvent adéquats dans de nombreux cas. Supposons que vous disposiez d'un répertoire dans lequel résident les fichiers de votre service comptable. Vous pouvez définir ces autorisations sur :

drwxrwxr-x  2 accounting accounting  12 Jan  8 15:13

L'utilisateur du service de comptabilité (le propriétaire de l'utilisateur) peut lire et écrire dans l'annuaire et les membres du accountinggroupe (ou groupe propriétaire) peut lire et écrire. D'autres (utilisateurs n'appartenant pas au service de comptabilité) peuvent cependant voir et exécuter ce qu'il y a à l'intérieur, ce que certains pourraient penser que c'est une mauvaise idée.

Donc, nous pourrions changer les autorisations en ceci :

drwxrwx---  2 accounting accounting  12 Jan  8 15:13 .

De cette façon, les autres utilisateurs qui ne sont ni propriétaires du dossier ni membres du groupe pourront faire n'importe quoi, car aucune autorisation de lecture, d'écriture ou d'exécution n'est spécifiée.

Affichage de l'ACL actuelle

Et si vous avez un stagiaire en comptabilité (Kenny) qui doit être capable de lire certains fichiers (ou même uniquement des fichiers appartenant à Fred, son manager) ? Ou peut-être que les membres du service commercial ont également besoin d'un accès accountingpropriétaire pour créer des factures pour l'équipe de Fred afin de facturer les clients, mais vous ne voulez pas que l'équipe de vente voie les autres rapports générés par l'équipe de Fred. Cette situation peut être compliquée car, avec des autorisations régulières, chaque fichier et répertoire ne peut avoir qu'un seul propriétaire d'utilisateur et de groupe à la fois. Ce genre de situation est ce que les listes de contrôle d'accès (ACL) Linux étaient censées résoudre.

Les ACL nous permettent d'appliquer un ensemble plus spécifique d'autorisations à un fichier ou à un répertoire sans (nécessairement) modifier la propriété et les autorisations de base. Ils nous permettent d'"ajouter" un accès pour d'autres utilisateurs ou groupes.

Nous pouvons voir l'ACL actuel en utilisant le getfaclcommander:

[root]# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---

Nous pouvons voir qu'il n'y a actuellement aucune ACL sur ce répertoire car les seules autorisations répertoriées sont pour l'utilisateur, le groupe et autre. Dans ce cas, il fallait s'y attendre, car je viens de créer ce répertoire dans le laboratoire et tout ce que j'ai fait a été d'attribuer la propriété.

 

Alors, commençons par ajouter une ACL par défaut :

Mise en place d'une ACL

La syntaxe pour définir une ACL ressemble à ceci :

setfacl [option] [action/specification] file

L'"action" serait -m(éditeur  -x(supprimer) et la spécification serait l'utilisateur ou le groupe suivi des autorisations que nous voulons définir. Dans ce cas, nous utiliserons l'option -d(défaut). Ainsi, pour définir l'ACL par défaut pour ce répertoire, nous exécuterons :

[root]# setfacl -d -m accounting:rwx /accounting

Après cela, nous pouvons maintenant voir les informations ACL par défaut pour ce répertoire :

[root]# getfacl /accounting
[root]# getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
default:user::rwx
default:user:accounting:rwx
default:group::rwx
default:mask::rwx
default:other::---

Et si Fred crée un fichier dans ce répertoire ?

[fred]$ touch test
[fred]$ ls -la
drwxrwx---+  2 accounting accounting  18 Jan  8 17:51 .
dr-xr-xr-x. 18 root  root  262 Jan  8 15:13 ..
-rw-rw----+  1 fred  accounting  0 Jan  8 17:51 test
[fred]$ getfacl test
# file: test
# owner: fred
# group: accounting
user::rw-
user:accounting:rwx  #effective:rw-
group::rwx  #effective:rw-

Et si Kenny essaie de créer un fichier ? Vous pourriez être en mesure de deviner que puisque  kennyce n'est pas dans accountinggroupe, n'aura pas la permission. Mais nous voulons que Kenny ait une bonne expérience de travail avec nous, nous devons donc lui donner la possibilité de voir quels fichiers se trouvent dans le accountingrépertoire et nous voulons qu'il puisse créer de nouveaux fichiers :

[root@lab1 accounting]setfacl -m kenny:rwx /accounting
[root]getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
user:kenny:rwx

Jusqu'ici tout va bien. Mais que se passe-t-il si nous ne voulons pas que cet utilisateur crée des fichiers dans le accountingrépertoires ? Au lieu de cela, nous voulons simplement qu'il lise les fichiers là-bas et qu'il puisse créer de nouveaux fichiers dans son dossier.

Nous pouvons définir l'accès de Kenny au accountingdossier comme celui-ci :

[root@lab1 accounting]# setfacl -m kenny:r-x /accounting
[root]# getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
User:kenny:r-x

Faisons maintenant de Kenny son dossier, donnons-lui la propriété, puis faisons le accountinggroupe le propriétaire du groupe afin que d'autres personnes dans le accountinggroupe peut voir ce qu'il y a à l'intérieur :

[root@lab1 accounting]# mkdir ./kenny
[root]# chown kenny:accounting ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:rwx
group::rwx

Vous avez créé un dossier dans le accountinggroupe appartenant à l'utilisateur kenny. Il est maintenant capable de voir le dossier de comptabilité, mais il ne crée que des fichiers dans son propre dossier :

[root@lab1 accounting]# su kenny
[kenny]$ touch test
touch: cannot touch ‘test’: Permission denied
[kenny]$ cd ./kenny
[kenny]$ touch test
[kenny]$ ls
test

Notez que puisque le dossier appartient au accountinggroupe, n'importe qui dans ce groupe peut y publier des fichiers. Puisque nous avons affaire à un stagiaire, ce facteur est probablement correct. Cependant, que se passe-t-il si nous donnons à Kenny une promotion au poste de réviseur principal et que nous voulons garder son travail secret pour Fred ?

[root]# setfacl -m fred:- ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---

Et si on ne voulait pas ça aucun voir sur quoi Kenny travaille?

[root]# setfacl -m g:accounting:- ./kenny

Observation: lorsque nous voulons définir une ACL de groupe , il faut le spécifier en préfixant g:le nom du groupe. Pour les utilisateurs, ça change juste gdans un u, Mais setfaclsupposons que nous parlons d'un utilisateur si vous n'y mettez rien.

Nous devons encore supprimer les autorisations de base du propriétaire du groupe afin que le reste de l'équipe comptable ne puisse pas espionner les rapports de Kenny :

[root]# chmod g-rwx ./kenny
[root]# ls -al
total 0
drwxrwx-wx+  3 accounting accounting  44 Jan  9 16:38 .
dr-xr-xr-x. 18 root       root       262 Jan  8 15:13 ..
drwx------+  2 kenny      accounting  18 Jan  9 17:07 kenny
-rw-rw----+  1 root       root         0 Jan  9 16:33 test
-rw-rw----+  1 kenny      accounting   0 Jan  9 16:27 test2
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
group::rwx  #effective:---
[root]# su jan
[jan]$ touch ./kenny/test
touch: cannot touch ‘./kenny/test’: Permission denied

Nous pouvons maintenant gérer qui d'autre peut voir ou écrire dans le dossier de Kenny sans changer de propriétaire. Donnons au PDG (Lisa, qui n'est pas membre de l'équipe comptable et n'aura pas accès au reste du dossier) accès aux affaires de Kenny :

[root@lab1 accounting]# useradd lisa
[root]# setfacl -m u:lisa:rwx ./kenny
[root]# su lisa
[lisa]$ touch ./kenny/lisa
[lisa]$ ls ./kenny
lisa  test
[lisa]$ touch test
touch: cannot touch ‘test’: Permission denied
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
user:lisa:rwx
group::rwx
group:accounting:---

Notez à nouveau que les autorisations du propriétaire du groupe restent entièrement ouvertes, mais le groupe comptable (qui est toujours le propriétaire) n'a plus accès à ce dossier. Alors à qui appartient-il ?

drwxrwx---+  2 kenny  accounting  30 Jan  9 17:16 kenny

Cette partie est délicate. Il est bon de savoir que nous pouvons supprimer les autorisations du propriétaire sans modifier le propriétaire, mais vous voudrez peut-être vous demander si c'est le résultat que vous souhaitez.

conclusion

Ce sont donc les bases. Les ACL peuvent prêter à confusion, je vous encourage donc à donner les pages de manuel setfacle getfaclune bonne lecture. Il existe de nombreuses autres choses intéressantes et utiles que vous pouvez faire avec ces outils, mais j'espère que vous en comprenez maintenant assez pour commencer.