Forum général.général Samba et ACL Posix

Posté par  (site web personnel) .
Étiquettes : aucune
0
27
fév.
2005
Hello,

je viens enfin de déployer mon cluster (à deux serveurs) Samba3. Tout est ok sauf un point de détail au niveau de la reprise des données des anciens systèmes (sous NT4): Je n'ai pas récupéré les ACL NT4.
Pas de panique, je devais les redéfinir de toutes façons étant donné que Samba 3.0.10 (sous Debian) ne supporte pas encore les nested groupes (groupes de groupes).

Néanmoins, je suis surpris du comportement général des ACL Posix. Il semble que les seuls utilisateurs autorisés à ajouter/modifier des ACL sur un fichier soient le propriétaire du fichier et root !

Or, sous NT4, j'avais défini un groupe d'admins qui pouvaient changer les ACL comme ils le voulaient, sans aucune difficulté. Quand j'ai voulu répéter le modèle, pas moyen de le mettre en fonction: même si le groupe est le groupe proprio du fichier avec les droits en rwx, pas moyen, en dehors du proprio de modifier les ACL (surtout, en rajouter...).
Malgré une petite après-midi de recherche sur le net, pas moyen de trouver des explications...
Ma 1ère question est donc la suivante:" quels utilisateurs peut effectivement manipuler les ACL Posix d'un fichier ?"

Ma 2ème question (qui dépend du résultat de la première) sera: "Existe-t-il un moyen (par système de fichiers, par samba, par autre chose), de permettre à des membres d'un groupe défini de modifier les ACL d'un fichier ?"

Merci pour votre contribution...
  • # Droits de modifs d'ACLs

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

    > Quels utilisateurs peut effectivement manipuler les ACL Posix d'un fichier ?

    Ben... le proprio s'il a w, le groupe s'il a w (y compris les users qui ont ce groupe comme secondaire), et "le reste de l'univers" s'ils ont w... enfin je crois... non ?
    • [^] # Re: Droits de modifs d'ACLs

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


      Ben... le proprio s'il a w, le groupe s'il a w (y compris les users qui ont ce groupe comme secondaire), et "le reste de l'univers" s'ils ont w... enfin je crois... non ?

      Ben non...

      J'ai fait un petit test avec les élements suivants:
      - admin1 et admin2 font partie d'un groupe (primaire) administrateurs.
      - j'ai créé un groupe groupe1 d'utilisateurs et aussi une groupe2 d'utilisateurs.
      - sous l'identité de admin1, j'ai créé une ACL sur un fichier (qui appartient à admin1).
      - voici ce qui se passe sous l'identité d'admin2:

      getfacl ./fichier_test3.acl
      # file: fichier_test3.acl
      # owner: admin1
      # group: administrateurs
      user::rwx
      group::rwx
      group:groupe1:r-x
      mask::rwx
      other::rwx

      medspxdeb:/data/share/ADMIN$ setfacl -m g:groupe2:rx ./fichier_test3.acl
      setfacl: ./fichier_test3.acl: Opération non permise


      J'ai volontairement mis les droits au max à tout le monde juste pour voir: pas moyen que ça marche. Par contre, dès que je reviens à admin1 ou à root, je peux changer l'ACL.
      • [^] # Re: Droits de modifs d'ACLs

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

        Coucou Médéric,
        a priori, ça présente le même comportement que les droits unix habituels.
        Si admin1 chmod 777 foo.bar, admin2 ne peut ni changer la propriété (chown) ni les privilèges (chmod) sur ce fichier. Le propriétaire demeure :

        man 5 setfacl :

        PERMISSIONS
        The file owner and processes capable of CAP_FOWNER are granted the
        right to modify ACLs of a file. This is analogous to the permissions
        required for accessing the file mode. (On current Linux systems, root
        is the only user with the CAP_FOWNER capability.)


        Il faudrait donc pouvoir supporter "plusieurs propriétaires", ou un "groupe propriétaire", pas encore possible apparemment.

        Jérôme.
      • [^] # Re: Droits de modifs d'ACLs

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

        > setfacl: ./fichier_test3.acl: Opération non permise

        OK... t'as monté ton FS avec l'option ACL ?

        mount -o remount,acl /point/de/montage

        Pareil, mets à jours ton /etc/fstab
        • [^] # Re: Droits de modifs d'ACLs

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

          Hahaha, ça ne serait pas "non permise" mais "non supportée" jeune padawan :p
          Donc, le FS est bien monté avec 'acl' mais c'est une histoire de droit.
          Voir le man de setfacl.
          • [^] # Re: Droits de modifs d'ACLs

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

            Hello et merci...

            Bon, en fait, c'était marqué dans le man de setfacl. J'ai parcouru la mailing list des dev, quelques complaintes à ce sujet mais pas d'implémentation réelle derrière.

            Va falloir se la jouer plus fin que ça: déjà , je vais me débrouiller avec les Defaults ACL sur les répertoires, ça permettra de mettre au moins des droits d'accès qui vont bien.
            Ensuite, en cas de soucis, il me reste toujours mon compte root pour faire le job (changer les ACL). Si ça devient ingérable, un petit script qui "chownise" à outrance...pas terrible mais à voir.
            • [^] # Re: Droits de modifs d'ACLs

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

              Dans le style goret, ya aussi le setuid root des outils acl.
              Un peu moins goret, mais ptet pas trop mal, le sudo pour ces mêmes outils. /etc/sudoers permet pas mal de finesse quant aux comptes ayant des droits accrus, ...
  • # Extendend Attributes

    Posté par  . Évalué à 1.

    Salut,

    Pour t'aider, un petit

    getfacl

    et ls -a

    nous aiderait pour te repondre.

    Ensuite, a tu compiler XFS avec les Extended ATTRibute et mis l'option coreespondante qui va bien dans smb.conf ?
    (mappage des flags DOS : READONLY, SYSTEM, ARCHIVE dans les Extend Attributes, plutot que l'ancienne bidouille "rwxrwxrwx", ce qui expliquerait tes problèmes.

    A+

    ( DRBD c'est bien mangez en ... )

    une doc de principe des droits avec ACL http://www.linuxplusvalue.be/mylpv.php?id=153(...)(...)

Suivre le flux des commentaires

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