Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

marioon · Le 14/06/2024, à 13:07

Bonjour,

Je me suis récemment mis en place un serveur de développement interne, en circuit fermé. Pour répondre à une logique bien particulière, j'ai dû faire une gestion des droits d'accès des fichiers/dossiers à contre-courant des préconisations en termes de sécurité informatique. Ça a le mérite de marcher et de m'avoir appris quelques trucs, et en plus de pouvoir développer mon application comme je l'entends.

Mais, je me suis dites que ce serait peut-être dommage d'en rester là. Il existe tant de possibilités sous Linux, qu'il devait probablement y avoir une solution plus élégante que celle que j'ai éprouvée. Après une recherche rapide, je découvre la notion de "Access Control List" qui permettrait une gestion plus fine des droits d'accès au système de fichiers. Cela pourrait répondre à mon besoin, sans entorse à des questions de sécurité. Ma solution actuelle n'en souffre pas dans le fond, car elle tourne en circuit fermée, mais j'apprécierai de disposer d'un système plus équilibré.

Une recherche rapide me montre que ce genre de système est potentiellement géré par Ubuntu : Les ACL, documentation.
Donc, en allant dans cette direction, je ne pense pas me tromper. Je souhaiterais profiter du retour d'expérience de personne qui ont utilisé (ou utilisent encore) ce genre de système. Éventuellement, me proposer des interfaces graphiques compatibles avec Cinnamon*.

Comprenez bien, qu'ici, ce qui m'importe c'est votre expérience en la matière. Ceci, les diverses documentations ne me l'apporteront pas.

Je vous remercie déjà du temps que vous m'accorderez.

* je ne dénigrerai pas la grande flexibilité des outils en ligne de commande. Ils sont géniaux. Mais je souffre d'une pathologie neurologique, et une interface graphique pourrait m'aider à ne pas souffrir (littéralement) de mes problèmes de concentration et de focalisation. Ainsi, enchainer des lignes de commande ouvre la voie à mes troubles neurologique (ce qui inclut des douleurs physiques importantes et durables). Je vous prie de ne pas apporter de commentaire, non-constructif, vis à vis de l'éventuelle adoption d'un outil graphique.

Dernière modification par marioon (Le 14/06/2024, à 14:25)

jplemoine · Le 14/06/2024, à 15:27

A partir du moment où c'est en circuit fermé, il n'y a pas de problème de sécurité dans ce qui avait été mis en place.
Les ACL sont plus beaucoup plus compliquées que les droits classiques et n'ont pas trop d’intérêt dans ce cas précis (hormis l’intérêt didactique).

C'est pour cela que je n'en ai pas parlées dans la discussion précédente. Perso, je te déconseille de les utiliser et je ne connais pas d'interface graphique.

marioon · Le 14/06/2024, à 16:22

jplemoine a écrit :

hormis l’intérêt didactique

Je comprends que l'utilisation des ACL peut sembler n'avoir un intérêt didactique, mais je voudrais souligner quelques points sur leur importance et leur utilité à la fois sur le plan fonctionnel et pour l'ouverture d'esprit en général. - Sous réserve d'avoir compris quelque peu leurs usages...

1. Intérêt Fonctionnel des ACL
Gestion Granulaire des Permissions : Les ACL permettent de définir des permissions spécifiques pour chaque utilisateur et groupe, au-delà des permissions traditionnelles (lecture, écriture, exécution) d'Unix. Cela offre une flexibilité indispensable dans les environnements multi-utilisateurs où les besoins en termes de sécurité et d'accès varient largement.

Simplicité et Précision : Dans de nombreux scénarios, les ACL peuvent simplifier la gestion des permissions. Par exemple, plutôt que de créer des groupes supplémentaires ou de manipuler les permissions de manière complexe, les ACL permettent d'attribuer directement les droits nécessaires à des utilisateurs spécifiques sans affecter d'autres utilisateurs. Dans mon cas de figure, cela pourrait être une réponse à mes problématiques de santé.

Interopérabilité avec les Systèmes Windows : Les environnements mixtes où coexistent des systèmes Windows et Linux bénéficient grandement des ACL, car elles offrent une compatibilité avec les systèmes de permissions NTFS, facilitant ainsi la gestion des fichiers partagés et des accès réseau.

2. Intérêt pour l'Ouverture d'Esprit
Compréhension Approfondie du Système de Fichiers : Apprendre à utiliser les ACL élargit la compréhension des systèmes de fichiers Linux. Cela aide à apprécier la complexité et la puissance des systèmes Unix/Linux et développe des compétences précieuses pour les administrateurs système.

Adaptabilité et Résolution de Problèmes : La connaissance des ACL et de leurs applications rend les administrateurs plus adaptables. Face à des besoins complexes en matière de sécurité et d'accès, ils peuvent proposer des solutions efficaces et robustes, augmentant ainsi leur capacité à résoudre des problèmes variés.

Diversité des Outils et Techniques : S'initier aux ACL encourage une approche proactive de l'apprentissage des différentes technologies et techniques disponibles sous Linux. Cela enrichit non seulement les compétences techniques mais aussi la capacité à choisir l'outil ou la méthode la plus appropriée en fonction des situations.

En somme, bien que les ACL puissent initialement sembler superflues pour certains, je soupçonne que leur maîtrise m'apporterait une valeur ajoutée significative à la fois pour la gestion des systèmes et pour le développement personnel et professionnel.

Dernière modification par marioon (Le 14/06/2024, à 16:24)

geole · Le 14/06/2024, à 16:44

Bonjour
D'après la documentation il faut cliquer sur le mot apt://acl
Puis comme cela n'est plus standard (J'ai peut-être mal compris : In sample, replace ext4 by ext3 (since acl is activated by default, it has no sense giving an example for ext4), il faudra préciser qu'elles sont à utiliser ( Cela fait quand même 4 commandes) puis cliquer sur le mot apt://eiciel
Je ne connais que le principe.

ylag · Le 14/06/2024, à 16:57

Bonjour,

Le paquet acl devrait être installé par défaut, sinon pour l'avoir :

sudo apt install acl

Le paquet eiciel fournirait une interface graphique pour gérer les ACL ...

Source : https://packages.ubuntu.com/noble/eiciel

Si on désire installer :

sudo apt install eiciel

N'ayant jamais testé la chose, à vous de voir si c'est bien fonctionnel ...

A+

geole · Le 14/06/2024, à 17:15

ll fonctionne bien en 22.04

marioon · Le 14/06/2024, à 17:24

geole a écrit :

Puis comme cela n'est plus standard

Je ne sais pas si l'on peut dire que c'est standard ou pas, mais le noyau du système est pensé pour accepter les ACL.

Pour l'instant, je ne souhaite pas me lancer dans son installation. Je préfère avoir au préalable des retours d'expérience. Les documentations ne me diront pas si on doit s'attendre dans le temps à devoir réviser la configuration de son système, ou si au contraire, une fois en place, cela est stable. Est ce que cela a posé problème vis à vis de certains logiciels ; est ce que ca a posé des problèmes d'adaptation pour les utilisateurs, etc. Même chose pour une interface graphique.

geole · Le 14/06/2024, à 17:30

La documentation donne un exemple pour des partitions formatées en EXT3 alors que maintenant le format EXT4 est utilisé.
Pour un peu je dirais qu'il n'y a rien à faite pour les partitions EXT4 à l'exception d'installer le pilote graphique et de l'utiliser en cliquant sur son icône.

sudo apt install acl --simulate
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait      
acl est déjà la version la plus récente (2.3.1-1).
acl passé en « installé manuellement ».

Je viens d'utiliser et de mettre une capture d'écran.

grep ACL /boot/config-$(uname -r)
CONFIG_XILINX_EMACLITE=m
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_JFS_POSIX_ACL=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_F2FS_FS_POSIX_ACL=y
CONFIG_FS_POSIX_ACL=y
CONFIG_NTFS3_FS_POSIX_ACL=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_JFFS2_FS_POSIX_ACL=y
CONFIG_EROFS_FS_POSIX_ACL=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_CEPH_FS_POSIX_ACL=y
CONFIG_9P_FS_POSIX_ACL=y

Dernière modification par geole (Le 14/06/2024, à 17:41)

marioon · Le 14/06/2024, à 17:34

Je me suis peut-être mal exprimée. Je ne recherche pas de l'aide pour une installation.

Je souhaite simplement avoir des retours d'expérience de personne qui l'ont utilisé ou qui l'ont testés, et savoir finalement ce qu'ils en retiennent, ce qu'il en pense, en bien ou en mal.

marioon · Le 14/06/2024, à 18:01

geole a écrit :

acl est déjà la version la plus récente (2.3.1-1).

Je ne suis qu'à moitié étonnée de constater que ACL serait préinstallé. Quand j'ai découvert le principe des ACL, je me suis dite que ca devrait mieux correspondre aux besoins de beaucoup d'entreprise. Le système de droit d'accès "à l'ancienne" doit être lourd à gérer pour de grandes entreprises.

erresse · Le 14/06/2024, à 18:06

Je n'ai pas plus d'expérience des ACL que mes petits camarades, je crois me souvenir que Cœur Noir a étudié en détail les partages et droits divers, peut-être a-t-il une expérience plus étendue des ACL ?
La seule chose que je peux dire, c'est que dans mon gestionnaire de fichiers (Caja car je suis sous Ubuntu-Mate), l'onglet "liste de contrôle d'accès" de la fenêtre des propriétés d'un objet (clic droit+"Propriétés") permet d'éditer les ACL en mode graphique.
De prime abord, ça n'a pas l'air trop compliqué à manipuler mais, comme je le disais précédemment, je n'ai pas essayé la chose et n'ai donc pas l'expérience pratique...

xubu1957 · Le 14/06/2024, à 18:15

Bonjour,

@erresse

Tu fais référence à ce fil > héritage de permissions ?

marioon · Le 14/06/2024, à 18:25

erresse a écrit :

De prime abord, ça n'a pas l'air trop compliqué à manipuler mais, comme je le disais précédemment, je n'ai pas essayé la chose et n'ai donc pas l'expérience pratique...

Justement, dans le fond, ca permet de nettement simplifier les droits d'accès. Ca evite de devoir trouver des astuces en créant divers groupes pour arriver à contourner le fait que pour un dossier ou un fichier, tu ne puisses spécifier qu'un seul groupe. Pour des systèmes avec un grand nombre d'utilisateurs qui induisent des configurations très variées, ca implique souvent de mettre en place un casse tête pour arriver à nos fins.

Avec les ACL, tu peux librement imaginer comment tu vas gérer les droits d'accès, tu peux créer autant de groupe que tu le souhaites pour les associer à tes fichiers/dossiers. Du coup, l'organisation de la gestion des droits peut être simplement en adéquation avec l'organisation de ton entreprise.

J'ai une question pour les personnes qui ont participé jusque-là. Avez-vous entendu parler des ACL avant ce post ? Cela suscite-t-il votre intérêt ?

Dernière modification par marioon (Le 14/06/2024, à 18:28)

jplemoine · Le 14/06/2024, à 18:28

En fait, quand tu as un grand nombre d'utilisateurs, tu gères les permissions au niveau des groupes et tu associes ou pas l'utilisateur au groupe en question.
Tu ne passe quasiment jamais par des ACL.
Je ne l'ai utilisé qu'une fois : Un "grand chef" voulait un accès en écriture à un répertoire qui faisait partie d'un tout.
C'était géré par un groupe qu'il ne fallait pas toucher.

marioon · Le 14/06/2024, à 18:33

jplemoine a écrit :

je te déconseille de les utiliser

Ce qui, je pense, serait intéressant, ce serait de nous expliquer pourquoi tu nous conseilles de ne pas les utiliser ? J'ai ouvert le sujet justement pour avoir les argumentaires des uns et des autres.

Toutefois, j'ai l'impression que pour quelques uns, cela porte une forme d'engouement. Alors je trouve intéressant d'en parler.

erresse · Le 14/06/2024, à 18:46

xubu1957 a écrit :

Bonjour,
@erresse
Tu fais référence à ce fil > héritage de permissions ?

Entre autres, mais je crois qu'il a fait un gros boulot sur le sujet, peut-être dans la doc. Voir par ici.

Coeur Noir · Le 14/06/2024, à 19:04

Les ACL sont utilisés par défaut à quelques endroits d'un système Ubuntu ( et autres distributions ).
Je ne saurais pas tous les citer mais je connais bien celui-là :
le dossier /media/$USER/ créé lors du branchement à chaud d'un stockage amovible~nomade ( dont la partition sera montée dans /media/$USER/uuid_ou_label_part ).

Le « problème » à l'usage des ACL, c'est qu'ils sont moins visibles « immédiatement » que les droits et permissions classiques.
Si on ne vérifie pas un peu plus en profondeur, si on oublie d'être attentif à cette question ça peut vite créer des confusions.

Donc avant de te mettre à utiliser des ACL, il faudrait d'abord t'assurer que ce que tu souhaites mettre en place dans ton « serveur de dév' interne » est vraiment impossible à atteindre avec les droits « classiques ».
Avec les notions d'utilisateur et de groupes, les droits classiques rwx et les droits spéciaux s et t, on a quand même déjà énormément de possibilités !

Les ACL sont utilisés dans des contextes précis où les droits classiques ne sauraient pas fournir l'objectif recherché.
C'est peut-être ton cas mais vaudrait mieux en être sûr ( j'aime assez ces question de droits et permissions : ça ne veut pas dire que j'aurai réponse à tout mais on peut fouiller un peu si tu veux, dans le contexte de ton serveur. )

Dernière modification par Coeur Noir (Le 14/06/2024, à 19:08)

marioon · Le 14/06/2024, à 19:12

Coeur Noir a écrit :

le dossier /media/$USER/ créé lors du branchement à chaud d'un stockage amovible~nomade ( dont la partition sera montée dans /media/$USER/uuid_ou_label_part ).

Est ce que ce serait qui explique que les ACL soient incluent dans le système ? Pour assurer une compatibilité avec les autres systèmes d'où viendraient ces médias ?

Coeur Noir a écrit :

Le « problème » à l'usage des ACL, c'est qu'ils sont moins visibles « immédiatement » que les droits et permissions classiques.

Est-ce une manière de dire que cela rompt avec les traditions d'usage, et que par conséquent cela pourrait être perturbant pour d'autres utilisateurs si ils ne sont pas avertis/habitués à cette fonctionnalité ?

Coeur Noir a écrit :

Donc avant de te mettre à utiliser des ACL, il faudrait d'abord t'assurer que ce que tu souhaites mettre en place dans ton « serveur de dév' interne » est vraiment impossible à atteindre avec les droits « classiques ».

En ce qui concerne mon projet, j'ai pu effectivement trouver une solution basé sur les droits classique. Mon cas est tordu, mais j'ai reçu de l'aide, et j'ai pu adapter effectivement avec les droits classiques. Mais étant de nature critique... hé bien, je m'autocritique, je me demande si il n'y avait pas moyen d'y arriver autrement. C'est une manière d'apprendre.

Dernière modification par marioon (Le 14/06/2024, à 19:18)

jplemoine · Le 14/06/2024, à 19:19

Je te déconseille de les utiliser parce que comme l'a dit "Coeur Noir", les droits classiques suffissent dans 99.9% des cas.
Il faut dans un premier temps maîtriser les droits classiques.
Si j'en crois mon expérience, ce n'est à utiliser que dans des cas exceptionnels (j'ai cité plus haut celui que je connaissais).
Dans ton cas, ça fonctionne : donc, je préconise de ne toucher à rien.
- ton utilisateur a les droits en écriture
- l'utilisateur www-data n'a les droits qu'en lecture
- il n'y a pas besoin d'autre chose (sauf erreur de ma part)

L'utilisation des ACL va cxompliqué les choses puisque tu ne verra pas (ou quasiment pas) avec un simple ls et il y a peu de tuto sur le sujet.
En voulant faire mieux, c'est un coup à tout casser.

Dernière modification par jplemoine (Le 14/06/2024, à 19:20)

marioon · Le 14/06/2024, à 19:53

jplemoine a écrit :

En voulant faire mieux, c'est un coup à tout casser.

Je comprends ton point de vue, mais permets-moi de (re)préciser (cf #1#3#9#19) que je trouve l'apprentissage des ACL particulièrement intéressant, non seulement sur le plan fonctionnel, mais aussi pour le développement personnel.

Bien que les ACL puissent sembler avoir un intérêt principalement didactique, je trouve leur apprentissage enrichissant et bénéfique pour mon développement personnel et professionnel. J'apprécierais donc des partages d'expériences sur leur utilisation pratique.

Dernier hors sujet : si je devais m'essayer aux ACL sur une machine virtuelle, je ne le ferais pas sur celle sur laquelle je développe mon projet. Je fais bien la séparation entre le domaine didactique, et le domaine professionnel (ou assimilable)

Dernière modification par marioon (Le 14/06/2024, à 20:00)

Coeur Noir · Le 15/06/2024, à 00:30

Est ce que ce serait qui explique que les ACL soient incluent dans le système ? Pour assurer une compatibilité avec les autres systèmes d'où viendraient ces médias ?

Non absolument pas. Mais c'est vrai que sans plus d'explication la parenthèse dans mon exemple pourrait le laisser croire.
La particularité du dossier /media/$USER - qui dans la session marioon s'appelera donc /media/marioon - c'est qu'il appartient à root:root mais qu'il ne donne qu'à marioon le droit de lire et écrire dedans.

marioon@son-super-pc:~$ ls -la /media/marioon
total 8
drwxr-x---+ 2 root root 4096 juin  14 19:45 .		# le + à droite des droits signifie la présence d'ACL, là on est sur le dossier marioon/
drwxr-xr-x  6 root root 4096 mai    9 02:40 ..		# ici on est sur le dossier media/
marioon@son-super-pc:~$

Si on ne regarde que les droits « classiques » l'utilisateur marioon n'est pas censé pouvoir lire ou écrire dans marioon/,
ce sont les droits ACL qui règlent cela ici ( dont la présence est indiquée par le + ) et qu'il faut consulter avec un autre outil :

marioon@son-super-pc:~$ getfacl /media/marioon/
getfacl : suppression du premier « / » des noms de chemins absolus
# file: media/marioon/
# owner: root
# group: root
user::rwx
user:marioon:r-x
group::r-x
mask::r-x
other::---
marioon@son-super-pc:~$

Dans ce contexte précis, l'idée c'est d'empêcher à l'$USER de supprimer trop facilement le contenu du dossier /media/$USER car il peut accueillir simultanément plusieurs points de montage pour des données provenant de divers supports. Dit autrement : branche des clés USB et des DD extenes, l'$USER pourra effacer des contenus DANS les syst. de fichiers de ces périphériques mais ne pourra pas en effacer la racine ( c'est heureux sinon ça reviendrait à supprimer toutes les données contenues dans les partition de ces supports, syst. de fichiers inclus. )

Avec les droits classiques on ne peut pas obtenir : « le dossier /media/$USER appartient à root:root mais seul l'utilisateur marioon peut écrire dedans. »
Dans ce cas particulier, les ACL offrent la combinaison de droits recherchée.

Est-ce une manière de dire que cela rompt avec les traditions d'usage, et que par conséquent cela pourrait être perturbant pour d'autres utilisateurs si ils ne sont pas avertis/habitués à cette fonctionnalité ?

Oui on peut le voir comme ça. Sauf qu'il ne s'agit pas de traditions mais bien du fonctionnement fondamental de l'OS, conçu dès le départ avec plusieurs utilisateurs, qui font partie de divers groupes.
Ces divers ensembles et sous ensembles circonscrivent qui a le droit de faire quoi et où.

Même pour un utilisateur aguerri, plus il y a d'éléments faisant l'objet d'ACL dans un système, plus ça en complique l'administration : par le manque de « visibilité » immédiate d'une part, et parce que chaque ACL est par nature imprévisible puisqu'il répond à un cas particulier ( tel ou tel besoin, mis en place par ou pour tel ou untel… ) or on peut vite oublier pourquoi on avait mis en place un ACL quelque part !

Quand on « déconseille » d'utiliser les ACL, ça n'est pas parce qu'ils seraient dangereux ou mauvais, ça fonctionne très bien.
Mais il serait terriblement risqué de s'en servir comme contournement d'une problématique qu'on ne saurait pas résoudre avec les droits classiques : il vaut mieux d'abord assimiler les droits classiques ( visibles, prévisibles, constants et presqu'universels ) plutôt que multiplier des sources « d'imprévisibilité » dans le système de fichiers. À long terme et selon la quantité d'éléments « avec ACL » c'est tout le contraire d'une « facilitation ! » Et il doit bien encore exister des noyaux Linux où les ACL ne sont pas activés ( ? ).

je me demande si il n'y avait pas moyen d'y arriver autrement. C'est une manière d'apprendre

Tu as raison. Ceux qui t'ont aidé ont été sages, ils ont orienté ton apprentissage dans un ordre chronologique, sain et sauf : d'abord saisir les possibilités et limites des droits « classiques » puis seulement pour des cas particuliers RARES où ils ne suffisent plus, employer les ACL.

Tu peux tenter l'expérience dans un environnement « étanche » où tu t'amuseras à créer plein d'éléments avec des ACL : au bout d'un moment tu auras du mal à t'y retrouver alors que c'est toi qui administres, imagine un peu ce qui se passera si quelqu'un d'autre que toi doit utiliser ou gérer ce système, pense à toutes les infos de réglages inhabituels que tu devras faire suivre à cette personne…

_______________________

Les droits « classiques » donnent un cadre déjà solide - avec quelques rares limitations - pour gérer qui fait quoi et où, afin d'éviter l'élévation de privilège ( éviter qu'un utilisateur inattendu acquiert les droits de l'utilisateur root le big boss. ) Ça n'est pas interdit de sortir du cadre à condition :
1⋅ d'en mesurer les conséquences, bénéfices ou inconvénients
2⋅ tout en s'assurant que l'utilisateur root reste strictement hors d'atteinte.

Dernière modification par Coeur Noir (Le 15/06/2024, à 00:54)

marioon · Le 15/06/2024, à 01:36

Coeur Noir a écrit :

[Avec les droits classiques on ne peut pas obtenir : « le dossier /media/$USER appartient à root:root mais seul l'utilisateur marioon peut écrire dedans. » Dans ce cas particulier, les ACL offrent la combinaison de droits recherchée.
(...)
Oui on peut le voir comme ça. Sauf qu'il ne s'agit pas de traditions mais bien du fonctionnement fondamental de l'OS, conçu dès le départ avec plusieurs utilisateurs, qui font partie de divers groupes.

Coeur Noir a écrit :

Même pour un utilisateur aguerri, plus il y a d'éléments faisant l'objet d'ACL dans un système, plus ça en complique l'administration : par le manque de « visibilité » immédiate d'une part, et parce que chaque ACL est par nature imprévisible puisqu'il répond à un cas particulier ( tel ou tel besoin, mis en place par ou pour tel ou untel… ) or on peut vite oublier pourquoi on avait mis en place un ACL quelque part !

Effectivement. en version "traditionnelle", on voit moins de droit, on a moins de question à se poser. A moins qu'on ne gère une très grande entreprise avec des droits complexes. Je ne serais pas surprise que les ACL soient inspirés de ces environnements, en plus des cas d'exception. Personnellement, je regrette que l'on ne puisse pas documenter les groupes et les utilisateurs (ou sinon en commentaire dans des fichiers de configuration, ce qui ne serait pas pratique du tout)... ou cela existe, mais je l'ignore et/ou c'est très peu utilisé, peu ancré dans les mœurs.

Coeur Noir a écrit :

Quand on « déconseille » d'utiliser les ACL, ça n'est pas parce qu'ils seraient dangereux ou mauvais, ça fonctionne très bien.

Jusqu'ici, j'y vois un danger, qui ressort d'ailleurs des commentaires : si c'est mal géré on peut se perdre par excès de confiance, et commettre des erreurs. Il faut par exemple substituer des commandes par d'autres compatibles avec les ACL, penser à activer un paramètre ACL dans les lignes de commande. Je dirais que les ACL peuvent être utilisées, soient pour les cas d'exception, soit si on est très organisé. Personnellement, je documente beaucoup. En ce moment, je créé une documentation chaque fois que je mets quelque chose en place de manière définitive.

Coeur Noir a écrit :

Mais il serait terriblement risqué de s'en servir comme contournement d'une problématique qu'on ne saurait pas résoudre avec les droits classiques : il vaut mieux d'abord assimiler les droits classiques ( visibles, prévisibles, constants et presqu'universels )

Oui, il faut absolument assimiler les bases, c'est indéniable. Même si on maitrise les ACL, de toute façon, la gestion de droit traditionnel fait partie des ACL. Mon intérêt pour les ACL est venu justement d'une problématique d'exception. Avec l'aide que j'ai reçu sur le forum, j'ai pu me dépatouiller, mais c'était une solution tordue. Ce soir, j'ai tenté de faire la même chose avec les ACL... et ca a été plus rapide, et tellement plus simple, sans pour autant (du moins je le crois) exposer le système en terme de sécurité. En terme de didactique, je trouve cela génial. Explorer les pour et les contre, confronter les connaissances, les pratiques avec les possibilités, ca ouvre l'esprit.

Coeur Noir a écrit :

plutôt que multiplier des sources « d'imprévisibilité » dans le système de fichiers. À long terme et selon la quantité d'éléments « avec ACL » c'est tout le contraire d'une « facilitation ! » Et il doit bien encore exister des noyaux Linux où les ACL ne sont pas activés ( ? ).

SI j'ai bien, ca fait partie de la norme POSIX, donc ce serait accessible sur la plupart des système UNIX de notre époque. Sur d'anciens systèmes, c'est une autre histoire.

je me demande si il n'y avait pas moyen d'y arriver autrement. C'est une manière d'apprendre

Tu as raison. Ceux qui t'ont aidé ont été sages, ils ont orienté ton apprentissage dans un ordre chronologique, sain et sauf : d'abord saisir les possibilités et limites des droits « classiques » puis seulement pour des cas particuliers RARES où ils ne suffisent plus, employer les ACL.

Coeur Noir a écrit :

Tu peux tenter l'expérience dans un environnement « étanche » où tu t'amuseras à créer plein d'éléments avec des ACL : au bout d'un moment tu auras du mal à t'y retrouver alors que c'est toi qui administres, imagine un peu ce qui se passera si quelqu'un d'autre que toi doit utiliser ou gérer ce système, pense à toutes les infos de réglages inhabituels que tu devras faire suivre à cette personne…

C'est ce que je fais, je teste dans des machines virtuelles sous virtualbox, avec dossier partagé avec l'hôte (windows). Ca me rajoute une complexité complémentaire sur ces dossiers partagés qui semblent bloqués en root:vboxsf au lieu d'un choix possible. Du coup, avec les ACL, j'ai pu ajouter un groupe supplémentaire et simplifier la synchronisation avec un dossier apache sans aucun blocage (je n'ai pas touché aux dossiers entre /home/.../mondossierpartagé). Je me retrouve avec un dossier qui contient tous les fichiers de mon projet, qui envoie les données de développement (partie web en phase d'écriture) instantanément dans le dossier apache correspondant. Cette partie de synchro est à revoir, pour l'instant, j'ai fait un lien symbolique, c'était le plus rapide pour faire les tests.

Dernière modification par marioon (Le 15/06/2024, à 01:45)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 14/06/2024, à 13:07

Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#2 Le 14/06/2024, à 15:27

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#3 Le 14/06/2024, à 16:22

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#4 Le 14/06/2024, à 16:44

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#5 Le 14/06/2024, à 16:57

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#6 Le 14/06/2024, à 17:15

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#7 Le 14/06/2024, à 17:24

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#8 Le 14/06/2024, à 17:30

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#9 Le 14/06/2024, à 17:34

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#10 Le 14/06/2024, à 18:01

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#11 Le 14/06/2024, à 18:06

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#12 Le 14/06/2024, à 18:15

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#13 Le 14/06/2024, à 18:25

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#14 Le 14/06/2024, à 18:28

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#15 Le 14/06/2024, à 18:33

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#16 Le 14/06/2024, à 18:46

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#17 Le 14/06/2024, à 19:04

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#18 Le 14/06/2024, à 19:12

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#19 Le 14/06/2024, à 19:19

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#20 Le 14/06/2024, à 19:53

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#21 Le 15/06/2024, à 00:30

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

#22 Le 15/06/2024, à 01:36

Re : Access Control List sous Linux/Ubuntu Cinnamon : système de fichier

Pied de page des forums