Journal Article sur les ACLs sur LinuxFrench

Posté par  .
Étiquettes : aucune
0
11
août
2004
Le système des droits sous Unix définit classiquement trois niveaux de droits : le propriétaire du fichier, le groupe du fichier et les autres. Cette hiérarchie à trois niveaux ne suffit pas dans certains cas (un utilisateur qui veut autoriser un autre utilisateur qui n'est pas dans son groupe à écrire dans un fichier par exemple).
Les ACLs (Access Control List) permettent de définir des politiques d'accès aux fichiers plus complexes.
Un article sur LinuxFrench explique comment les mettre en oeuvre : http://www.linuxfrench.net/gnu_linux/comment_fonctionnent_les_acl_p(...)

  • # Ouip

    Posté par  (site web personnel) . Évalué à 4.

    C'est interressant de le poster, meme si ca à surement déjà été fait.
    Ca permet de montrer a ceux qui ne le savent pas encore comment gerer des droits un peu plus complets (facon windows) que les droits ancestraux unix qui peuvent très vite trouver une limite.
    Bref, un truc que tout le monde devrait savoir, au meme titre que chmod

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Ouip

        Posté par  (site web personnel) . Évalué à 1.

        'Ancestraux' n'est pas péjoratif.
        Je n'ai pas critiqué gratuitement ces droits, mais comme tu le dis toi meme, ils sont simples.
        Pour la gestion de droit avancé sans se prendre la tete les acl sont bien mieux, quoique t'en penses. Maintenant pour les 3/4 des users, rwx pour u g o a c'est nettement suffisant, et auquel cas, le fait d'activer les acl pour une partition n'oblige absolument pas l'utilisateur a les utiliser. il peut ainsi y avoir recours dans des cas exceptionnel, là ou il se rendra compte que plutot que de se prendre la tete, il peut utiliser les acl.

        voilà tout.

    • [^] # Re: Ouip

      Posté par  . Évalué à 3.

      ya des droits sous windoze ?

      plus sérieusement, en fat32, les droits c'est un peu n'importe quoi, et en ntfs, j'y ai jamais rien pigé, contrairement au chmod ugo+/-rwx ancestral de unix... ;)

      m'enfin, c'est quand même bien de mettre le lien :)

      • [^] # Re: Ouip

        Posté par  (site web personnel) . Évalué à 2.

        J'ai entendu dire quelque part que sous NT/2k/XP, yavait moyen de mettre des droits "complexes" genre ACL sur "tout" et donc qu'il était possible de régler les droits d'accès beaucoup plus finement que sous *nix. Le problème c'est que c'est plus compliqué à mettre en place que de s'amuser avec chmod et que donc pratiquement personne ne le faisait. Enfin c'est ce que j'ai lu quelque part, si un Windowsien peut {in|con}firmer...

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Ouip

          Posté par  (site web personnel) . Évalué à 3.

          Compliqué ? tu cliques droit, propriétés, puis à un moment si tu ne l'as jamais fait il te faudra cliquer sur "avancé" ou "activer les droits d'accès complexes", ou un truc du genre (me souviens plus, désolé). Là tu peut ajouter/retirer des utilisateurs par leur nom (via une interface tout ce qu'il y a de simple).

          De ce coté ce qui est "complexe" ce n'est pas l'interface, c'est la notion d'utilisateur et droit d'accès. Si tu es capable de comprendre la gestion des droits Unix les ACL Windows te seront comprehensibles en 2 minutes chrono en main. Quand tu valides sur un dossier il te demande si il doit faire les modifs récursivement sur les sous dossiers et fichiers. Je crois même que tu as une coche pour définir si les droits sont héritables ou pas (à vérifier).

          Franchement c'est effectivement un point où Win a de l'avance (je met "a" et non "avait" car pour moi ça sera bon quand les ACL seront répandues et gérées par tous les softs qui manipulent les droits d'accès, principalement les explorateurs de fichier).

  • # Cette hiérarchie à trois niveaux suffit

    Posté par  . Évalué à 1.

    >Cette hiérarchie à trois niveaux ne suffit pas dans certains cas (un utilisateur qui
    >veut autoriser un autre utilisateur qui n'est pas dans son groupe à écrire dans
    >un fichier par exemple)

    En fait si, c'est tout à fait faisable. Pour cela, il faut:
    - créer un nouveau groupe
    - y placer les deux utilisateurs
    - donner le fichier au nouveau groupe
    - donner les permissions qui vont bien

    Bon, la grosse différence quand même, c'est qu'il faut créer un groupe spécialement pout l'occasion, ce qui :
    - est plus fastidieux,
    - peut finir par devenir ingérable à la longue, et surtout
    - requiert les droits root.

    • [^] # Re: Cette hiérarchie à trois niveaux suffit

      Posté par  (site web personnel) . Évalué à 2.

      Oui, mais ce n'est pas parfait. Parce que quand mon copain écrira ses fichiers ils appartiendront par défaut à son groupe par défaut, pas à notre groupe commun.
      Il y a trois paliatif :
      - une commande qui permet de changer le groupe effectif pour que mon copain puisse prendre l'identité du groupe pendant sa session de travail sur le dossier commun. J'ai remarqué que l'outil en question était très peu connu, ne marchait pas sur toutes les distrib (voire n'était pas présent) mais bon, au mieux ça demande une manipulation explicite manuelle, puis de revenir à l'état précédent une fois qu'il a finit de manipuler les fichiers communs : non satisfaisant.
      - changer le groupe à chaque fois après avoir écrit les fichiers dans le répertoire commun. C'est vite lourd et on a vite fait d'oublier.
      - faire un setgid sur le répertoire, ce qui a d'autres implications et n'est pas toujours satisfaisant non plus.

      Bref, il manque l'héritage des ACL, qui est bien pratique pour ce cas là justement.

    • [^] # Re: Cette hiérarchie à trois niveaux suffit

      Posté par  . Évalué à 2.

      L'exemple donné dans le texte n'est pas le bon.
      On rencontre la vrai limite des droits Unix dans le cas suivant :
      On veut un groupe en execution seule sur un repertoire (les utilisateurs) et un groupe en lecture/ecriture/execution (les admins du programe). Ben là ca devient complexe. Bonjour la floraison de SetUID et de SetGID....
      Si dérrière il faut un groupe en lecture/execution (pour l'audit) et un groupe en lecture seule (pour les back-ups) c'est carrément la fête au village.

      Kha

  • # Precision

    Posté par  (site web personnel) . Évalué à 1.

    A noter que sous debian (unstable), la commande ls indique bien un '+' sur les lignes contenant des ACL, contrairement a ce que dit la doc qui prétend que c'est seulement sur suse...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.