7 décembre 2022

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

Surmontez les limitations du système de fichiers Linux avec les listes de contrôle d'accès Linux standard POSIX

Liste de contrôle d'accès Linux-ACL

Les listes de contrôle d'accès Linux, appelées listes de contrôle d'accès (ACL), sont un outil essentiel pour obtenir un contrôle plus détaillé et granulaire des autorisations au sein du système de fichiers Linux. Même si elles peuvent sembler complexes au premier abord, les ACL sont essentielles pour gérer efficacement les autorisations, en particulier dans un environnement d'entreprise moderne où il est crucial de déterminer qui peut accéder à des informations spécifiques.

Dans le passé, l'accès aux systèmes de fichiers Linux était géré via un système d'autorisations plus général et moins spécifique. Toutefois, avec l’évolution des besoins des entreprises, il est devenu de plus en plus important de disposer d’un contrôle d’accès plus fin et personnalisé. Les ACL, une extension de la gestion traditionnelle des autorisations sous Unix, répondent à ce besoin.

Il est important de noter que le terme « ACL » peut avoir différentes significations selon le contexte. Pendant sous Linux, cela fait spécifiquement référence à la gestion des autorisations du système de fichiers, dans d'autres domaines, comme dans la gestion de l'accès aux services HTTP, indique le contrôle de l'accès à des services ou des ressources spécifiques. Bien que l'acronyme reste le même, sa signification varie selon le contexte d'utilisation.

D'un point de vue historique, POSIX a proposé quelques versions (POSIX 1003.1e et POSIX 1003.2c) pour étendre la gestion des autorisations dans les systèmes Unix, mais celles-ci n'ont pas été finalisées. Cependant, bon nombre de ces extensions ont été publiées et adoptées par divers systèmes Unix, y compris les systèmes GNU/Linux. Les extensions appelées « ACL », ou « ACL POSIX » dans certains contextes, ne représentent qu'une partie de ces propositions et sont particulièrement pertinentes pour la gestion des autorisations dans les systèmes GNU/Linux. Ce chapitre se concentre sur la description et la mise en œuvre des ACL dans de tels systèmes.

 

Revoir les bases des autorisations sous Linux

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 :

  • Lire _
  • Écrire _
  • 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.

Activer la prise en charge ACL sous Linux

Pour activer la prise en charge des listes de contrôle d'accès (ACL) sous Linux, un travail spécifique est requis sur la configuration du système de fichiers via le /etc/fstab. Ce fichier, situé dans le chemin /etc/fstab, joue un rôle crucial dans la gestion des systèmes Linux, car il définit comment les disques durs ou les partitions doivent être automatiquement montés par le système d'exploitation au démarrage et quelles options de montage doivent être appliquées.

Le fichier /etc/fstab contient une série d'entrées, chacune représentant un périphérique de stockage ou une partition, et spécifie comment celles-ci doivent être intégrées dans le système de fichiers global. Ces entrées incluent des détails tels que l'identifiant unique du périphérique, le point de montage dans le système de fichiers (c'est-à-dire l'emplacement où le contenu du périphérique sera accessible), le type de système de fichiers (tel que ext4, xfs, btrfs, etc.), et un certain nombre d'options de montage.

Pour activer les ACL, il est indispensable d'ajouter l'option acl aux entrées pertinentes du fichier /etc/fstab. Cet ajout indique au système que la prise en charge des ACL doit être activée lors du montage du système de fichiers ou de la partition spécifié. Sans cette spécification, les ACL ne pourraient pas être correctement appliquées ou gérées sur ce système de fichiers ou cette partition particulière, limitant ainsi la capacité d'affiner l'administration des autorisations de fichiers.

Exemple de configuration fstab avec les ACL activées

Voici un exemple de ce à quoi pourrait ressembler une entrée dans le fichier fstab avec les ACL activées :

UUID=1234abcd-12ab-34cd-56ef-1234567890ab /exemple ext4 valeurs par défaut, acl 0 2

Dans cet exemple, nous montons une partition avec UUID 1234abcd-12ab-34cd-56ef-1234567890ab au point de montage /example avec le système de fichiers ext4. L'option defaults applique un ensemble d'options de montage prédéfinies, tandis que acl Activez explicitement la prise en charge des ACL.

Considérations sur les différents systèmes de fichiers

Il est important de noter que même si les systèmes de fichiers comme ext3 ed ext4 exiger l'activation explicite des ACL via fstab, d'autres systèmes de fichiers modernes comme XFS o Btrfs avoir la prise en charge ACL activée par défaut. Cela signifie que pour ces derniers systèmes de fichiers, il n'est pas nécessaire de modifier le fichier fstab pour activer les ACL, sauf si vous souhaitez modifier les paramètres par défaut.

Si vous vous demandez quel système de fichiers est le plus adapté à vos besoins, lisez notre article sur le sujet : Guide des systèmes de fichiers pour Linux

Affichage de l'ACL actuelle

Imaginons un scénario dans lequel nous avons un stagiaire en comptabilité nommé Kenny, qui a besoin d'accéder à certains fichiers, peut-être ceux de Fred, son manager. Ou encore, imaginez une situation dans laquelle le service commercial a besoin d'accéder aux fichiers comptables appartenant à Fred pour créer des factures permettant à l'équipe de Fred de facturer les clients. Cependant, nous ne souhaitons pas que l'équipe commerciale ait accès à d'autres rapports générés par l'équipe de Fred. Ces situations posent un défi en termes de gestion des autorisations : dans un système d'autorisations standard, chaque fichier et répertoire ne peut avoir qu'un seul propriétaire et un groupe d'utilisateurs associés. C'est dans ces circonstances que les listes de contrôle d'accès (ACL) Linux deviennent particulièrement utiles.

Les ACL nous permettent d'attribuer un ensemble d'autorisations plus détaillé et spécifique à un fichier ou un répertoire, sans nécessairement avoir à modifier les autorisations et la propriété sous-jacentes. En pratique, ils nous offrent la possibilité d'« ajouter » des accès pour d'autres utilisateurs ou groupes, en plus de ceux déjà existants.

Pour afficher l'ACL actuelle d'un fichier ou d'un répertoire, nous utilisons la commande getfacl. Par example:

[racine]# getfacl / comptabilité
getfacl : Suppression du « / Â» initial des noms de chemin absolus
#fichier : comptabilité
# propriétaire : comptabilité
# groupe : comptabilité
utilisateur ::rwx
groupe ::rwx
autre::---

Dans cet exemple, nous pouvons voir qu'il n'y a actuellement aucune ACL supplémentaire dans ce répertoire, car les seules autorisations répertoriées sont les autorisations standard pour l'utilisateur, le groupe et autres. Dans ce cas précis, il est normal de s'attendre à cette situation, surtout si le répertoire vient d'être créé dans un environnement de test et qu'aucune autre opération n'a été effectuée autre que l'attribution de propriété.

 

 

Commençons donc par ajouter une ACL par défaut.

Définition d'une ACL sous Linux

La configuration des listes de contrôle d'accès (ACL) sous Linux offre une flexibilité significative dans la gestion des autorisations de fichiers. La syntaxe de définition d'une ACL est structurée comme suit :

fichier setfacl [option] [action/spécification]

L'option « action Â» peut être -m (éditeur -x (supprimer), et la spécification indique l'utilisateur ou le groupe suivi des autorisations que vous souhaitez définir. Par exemple, pour définir une ACL par défaut sur un répertoire, nous utilisons l'option -d (défaut). La commande suivante définit l'ACL par défaut sur le répertoire /accounting:

[racine]# setfacl -d -m comptabilité:rwx / comptabilité

Après avoir exécuté cette commande, nous pouvons afficher les ACL par défaut pour ce répertoire avec :

[racine]# getfacl / comptabilité
# sortir:
#fichier : comptabilité
# propriétaire : comptabilité
# groupe : comptabilité
utilisateur :: rwx
groupe ::rwx
autre::---
par défaut: utilisateur :: rwx
par défaut : utilisateur : comptabilité : rwx
par défaut: groupe :: rwx
par défaut: masque :: rwx
par défaut:autre::---

Scénarios d'utilisation des ACL

La syntaxe de définition d'une ACL sous Linux est généralement structurée comme suit :

fichier setfacl [option] [action/spécification]

L’« action » peut être -m (éditeur -x (suppression). La « spécification » fait référence à l'utilisateur ou au groupe suivi des autorisations que vous souhaitez définir. Dans cet exemple, nous utiliserons l'option -d (défaut). Pour définir l'ACL par défaut d'un répertoire, vous exécuterez la commande :

[racine]# setfacl -d -m utilisateur: comptabilité: rwx / comptabilité

Après avoir exécuté cette commande, nous pouvons vérifier les ACL par défaut pour ce répertoire :

[racine]# getfacl / comptabilité
[root]# getfacl : Suppression du « / Â» initial des noms de chemin absolus
#fichier : comptabilité
# propriétaire : comptabilité
# groupe : comptabilité
utilisateur :: rwx
groupe ::rwx
autre::---
par défaut: utilisateur :: rwx
par défaut : utilisateur : comptabilité : rwx
par défaut: groupe :: rwx
par défaut: masque :: rwx
par défaut:autre::---

Supposons maintenant que Fred crée un fichier dans ce répertoire :

[fred]$ test tactile
[fred]$ls -la
total 0
drwxrwx---+ 2 comptabilité comptabilité 18 janvier 8 17:51 .
dr-xr-xr-x. 18 racine racine 262 8 janvier 15:13 ..
-rw-rw----+ 1 fred comptabilité 0 8 janvier 17:51 test
[fred]$ test getfacl
# fichier : tester
# propriétaire : Fred
# groupe : comptabilité
utilisateur ::rw-
utilisateur: comptabilité: rwx #effectif: rw-
group::rwx #effectif:rw-

Si au contraire Kenny essaie de créer un fichier, puisqu'il ne fait pas partie du groupe accounting, il n'aura pas la permission. Cependant, nous souhaitons que Kenny ait une expérience professionnelle positive, nous lui accordons donc l'accès à l'annuaire. accounting et on lui permet de créer de nouveaux fichiers :

[root@lab1 comptabilité]# setfacl -m utilisateur:kenny:rwx /accounting
[racine]# getfacl .
# des dossiers: .
# propriétaire : comptabilité
# groupe : comptabilité
utilisateur ::rwx
utilisateur:kenny:rwx

Mais si nous ne voulons pas que Kenny crée des fichiers dans le répertoire accounting, mais seulement qu'il lit les fichiers existants et crée de nouveaux fichiers dans son dossier personnel, nous pouvons définir ses autorisations comme ceci :

[root@lab1 comptabilité]# setfacl -m utilisateur:kenny:r-x /accounting
[racine]# getfacl .
# des dossiers: .
# propriétaire : comptabilité
# groupe : comptabilité
utilisateur ::rwx
utilisateur:kenny:rx

Nous créons ensuite un dossier personnel pour Kenny, lui en donnons la propriété et faisons en sorte que le groupe accounting propriétaire du groupe, afin que les autres membres du groupe puissent voir ce qu'il contient :

[root@lab1 comptabilité]# mkdir ./kenny
[racine]# chown kenny:comptabilité ./kenny
[racine]# getfacl ./kenny
# fichier : Kenny
# propriétaire : Kenny
# groupe : comptabilité
utilisateur ::rwx
groupe ::rwx

Kenny peut maintenant voir le répertoire accounting, mais ne peut créer des fichiers que dans son propre dossier :

[root@lab1 comptabilité]# sur Kenny
[kenny]$ test tactile
touch : impossible de toucher à « test Â» : autorisation refusée
[kenny]$cd ./kenny
[kenny]$ test tactile
[kenny]$ls
test

Si nous accordons à Kenny une promotion au poste de réviseur principal et souhaitons que son travail reste confidentiel, nous pouvons limiter l'accès à Fred :

[racine]# setfacl -m utilisateur:fred:- ./kenny
[racine]# getfacl ./kenny
# fichier : Kenny
# propriétaire : Kenny
# groupe : comptabilité
utilisateur ::rwx
utilisateur:comptabilité:---
utilisateur:fred:---

Et si nous voulons que personne d'autre que Kenny ne voie son travail ?

[racine]# setfacl -m groupe: comptabilité:- ./kenny
[racine]# getfacl ./kenny
# fichier : Kenny
# propriétaire : Kenny
# groupe : comptabilité
utilisateur :: rwx
groupe:comptabilité:---

Conclusion : comprendre et appliquer les ACL sous Linux

Compte tenu de leur complexité et de leur polyvalence, il est fortement recommandé de consacrer du temps à la lecture et à la compréhension des pages du manuel (man pages) Pour setfacl e getfacl. Ces pages offrent un guide complet et détaillé sur la façon d'utiliser ces outils, y compris les différentes options et indicateurs disponibles, fournissant des exemples pratiques et des explications approfondies.

En plus des fonctionnalités de base, setfacl e getfacl ils offrent un certain nombre d'options avancées qui peuvent être extrêmement utiles dans des scénarios spécifiques. Par exemple, vous pouvez configurer des ACL par défaut pour les nouveaux répertoires et fichiers d'un répertoire, ou gérer les masques ACL qui affectent les autorisations réelles.

Expérimentez dans un environnement contrôlé

Pour bien comprendre le fonctionnement des ACL, il est préférable d’expérimenter dans un environnement de test sécurisé. La création de différents scénarios, tels que la gestion des autorisations pour différents utilisateurs et groupes, peut aider à visualiser comment les ACL affectent l'accès aux fichiers et aux répertoires. Ce type de pratique est essentiel pour développer une solide intuition sur comment et quand utiliser les ACL dans des contextes réels.

Applications pratiques

Les ACL peuvent être particulièrement utiles dans les environnements multi-utilisateurs, tels que les serveurs d'entreprise, où différents départements ou équipes ont besoin d'un accès spécifique à certains fichiers. Ils sont également essentiels pour la sécurité des données, vous permettant de restreindre l'accès aux informations sensibles et garantissant que seuls les utilisateurs autorisés peuvent modifier ou visualiser certains fichiers.

Prendre en compte les meilleures pratiques

Lorsque vous travaillez avec des ACL, il est important de suivre les meilleures pratiques, par exemple en veillant à ne pas accorder d'autorisations excessives qui pourraient compromettre la sécurité du système. Il est également crucial de suivre les modifications que vous apportez, en particulier dans les environnements de production, afin d'éviter tout problème d'accès ou de sécurité.

conclusion

En conclusion, même si les ACL peuvent sembler intimidantes au premier abord en raison de leur complexité, une fois comprises, elles s'avèrent être un outil indispensable pour une gestion sophistiquée et détaillée des autorisations sous Linux. Passez du temps à les comprendre et à les mettre en pratique pour exploiter pleinement leur potentiel, rendant votre système plus sûr, plus efficace et adapté aux besoins spécifiques de votre environnement de travail.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de The FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

Retour en haut de page