Journal Samba + ACL: the mistery machine !

Posté par  (site web personnel) .
Étiquettes :
0
15
mar.
2005
Hello,

toujours dans mon projet (qui est finalement en prod parce que suffisant pour l'instant) de cluster HA Samba, j'avais des problèmes d'ACL Posix (voir le forum: http://linuxfr.org/forums/12/7114.html(...) Samba et ACL Posix.)

Je précise que l'ensemble tourne sous Debian Sarge et que dans le pot pourri on trouve les couches suivantes:
- Samba 3.0.10
- OpenLDAP 2.1 (over outdated mais stable donc on ne se plaint pas)
- Heartbeat
- DRBD 0.7.7
- CUPS
- LVM2 + XFS +Quotas
- smbldap-tools

Aujourd'hui, je contacte un de mes "co-admins" pour mettre en place les droits qui vont bien sur un répertoire Samba spécifique vu que, comme indiqué dans le message du forum, seul le compte root pouvait modifier les ACL des fichiers ne lui appartenant pas.
Quelle ne fût pas ma surprise lorsqu'il m'a répondu: "C'est OK, j'ai réglé les histoires de droits tout seul !"...

J'ai voulu vérifier quand même: je me pointe sur le répertoire par un client Win2K et je mate les onglets de sécurité. En effet, les droits ont été changés sur le répertoire et les fichiers alors que tout ce beau monde appartient à root !
Bon, je mate directement sur le serveur (getfacl) et tout correspond pile poil !!!!
Je supprime les ACL d'un fichier pour test, vérifie bien que le fichier appartient à root et je demande à mon collègue de refaire la manip (client win2k aussi) en direct: et ni plus ni moins, il me recolle des ACL en veux-tu en voilà comme si de rien n'était....

Je n'y comprends plus rien: je n'ai fait aucun changement sur le serveur depuis le déploiement où j'avais noté mes problèmes d'ACL qui m'ont paru logiques: sous Unix, seul root peut changer le propriétaire des fichiers. De même, la doc de setfacl précise bien que seul root est l'utilisateur qui peut ajouter des ACL sur des fichiers ne lui appartenant pas (au sens Posix du terme et non au sens NTFS). La seule chose qui, potentiellement a légèrement bougé, c'est le contenu de mon arbre LDAP (et encore: j'ai ajouté quelques users de base et quelques groupes).

Donc, je ne sais plus quoi penser. Néanmoins, pour la journée de demain, je vais me concoter quelques tests pour voir d'où ça vient parce que c'est comme si mon problème du début n'existait plus (ce qui est une bonne nouvelle: je vais pouvoir déléguer mes attributions de droits à mes collègues donc moins de taff lourdingue pour moi):
- Première supposition: sous Unix, seul root peut faire ce machin; or, chez moi, samba est lancé par root (mais dans ce cas, pourquoi j'ai eu des problèmes au début)!
- Deuxième supposition: peut-être que tout vient de mon arbre LDAP et auquel cas, il faut que je vois où j'ai pu me tromper.

Bon, les tests pour demain:
- Refaire un test d'attribution des droits avec des users du groupe des administrateurs Samba(différent de root).
- Faire ce test sur des répertoires nouvellement créés
- Refaire le test avec des répertoires sans ACL par défaut et avec
- Créer un groupe tout neuf et des users et voir si on peut reproduire les effets précédents.
- Voir si le fait d'ajouter les SID dans la définition du groupe (LDAP: PosixGroup + SambaGroup) ne règle pas la question.

Ma conclusion du jour: faut que je retourne bosser au plus vite pour éclairci ce mystère...
  • # Une idée

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

    - Refaire un test d'attribution des droits avec des users du groupe des administrateurs Samba(différent de root).
    Samba tournant en root si samba pense que l'utilisateur à le droit (il est administrateur) il fera le changement (en temps que root).
  • # Sympa

    Posté par  . Évalué à 4.

    Ouah, sympa ton projet !
    Tu as documenté ce que tu as fait ? Tu peux nous en faire profiter ? Ou bien les docs que tu as utilisé..

    Merci d'avance _o/
  • # Extended 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(...)
    • [^] # Re: Extended Attributes ?

      Posté par  . Évalué à 2.

      Salut,

      Je m'intéresse à ce genre de cluster HA, et j'étais tombé sur ENDB pour faire l'équivalent de DRBD (il y avait eu un article sur le sujet dans Linux Magazin (de)). Est-ce que tu as eu une expérience avec ? Se valent-ils ?

      Merci :)
      • [^] # Re: Extended Attributes ?

        Posté par  . Évalué à 1.

        Prend le horsserie n°18 de linux magazine france

        tu as un tres bon article pour drbd.

        J'ai en prod 1 (enfin 2) serveurs avec DRBD, c'est que du bonheur, temps d'indisponibilité maxi : 15 secondes ....

        DRBD + EXT3 (journalisé) + Heartbeat .... miam ...

        A+
      • [^] # Re: Extended Attributes ?

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

        j'en ai un en prod depuis 2001, ça marche nickel, le master c'est mistérieusement etteint et comme j'avais oublié de le monitorer je m'en suis rendu compte plusieurs jours plus tard ... les services était toujours dispo !
        Je suis en train d'en mettre 2 autres en places (4 machines).
        http://www.crium.univ-metz.fr/docs/system/drbd/(...)
  • # Et ton collègue ?

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

    Il se connecte en tant que quoi ton collègue ? En tant que root, en tant que n'importe qui, en tant qu'un co-admin (disons root1) de la machine, de samba ?
  • # Une question à 1000 euros au passage...

    Posté par  . Évalué à 2.

    puisqu'on parle de samba:

    Est-il possible de passer de Active Directory + authentification kerberos + GPO à Samba + openldap ?
    • [^] # Re: Une question à 1000 euros au passage...

      Posté par  . Évalué à 2.

      non

      tu auras toujours besoin d'un contrôleur de domaine A.D. si tu veux un réseau A.D. En tout cas il y a quelques mois c'était comme ça.
      • [^] # Re: Une question à 1000 euros au passage...

        Posté par  . Évalué à 2.

        François,

        merci de ta réponse, mais j'ai un peu de mal à saisir... je ne connais pas grand-chose à tout ça (je rapporte ici le problème d'un ami), il me semblait que samba pouvait faire office de contrôleur de domaine.

        Du coup, sans Active Directory, peut-on se rapprocher le plus possible de la configuration initiale avec Samba + OpenLdap, ou dans le cas contraire, qu'est-ce qui n'a pas encore d'alternative côté libre ?
        • [^] # Re: Une question à 1000 euros au passage...

          Posté par  . Évalué à 2.

          ce que tu peux faire avec Samba + OpenLDAP, c'est un contrôleur de domaine NT4 (PDC), pas Active Directory.

          En résumé :
          Réseau NT4 : tu peux te passer complètement des serveurs MS
          Réseau W2K : tu dois garder le contrôleur de domaine A.D. Tu peux, avec Samba, joindre un domaine Active Directory en tant que serveur membre, pour par exemple partager des ressources, mais tu auras toujours besoin d'un contrôleur MS.
          • [^] # Re: Une question à 1000 euros au passage...

            Posté par  . Évalué à 2.

            OK, c'est beaucoup plus clair maintenant, merci encore !

            (ce qui est surtout clair, c'est que les gens que je connais sont pied et poing liés à Microsoft...)
  • # UP

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

    Hello,

    bon ben ça marche comme il faut finalement !
    Donc, les seuls changements que j'ai fait sont la mise en place d'ACL par défaut (avec dedans les droits en rwx pour les administrateurs du domaine : le groupe Posix 512 et le groupe Samba dont le SID se termine par 512) et surtout, ajouter des users à ce groupe !!!

    Seuls les utilisateurs de ce groupe peuvent changer les ACL sur les fichiers et les répertoires(qui ne leur appartiennent pas). J'ai essayé avec un autre utilisateur hors de ce groupe, il ne peut pas le faire. Par contre, dès que je l'ajoute au groupe 512, pas de problèmes. Dans l'annuaire LDAP, l'ajout ou non du SambaSIDList n'a aucun effet.

    De plus, pour un autre groupe que le 512 (un groupe samba d'utilisateurs d'un secteur par exemple), même si je mets les droits en ACL par défaut sur un répertoire , en contrôle total (rwx) pour ce groupe, un utilisateur de ce groupe ne peut pas modifier les ACL.

    Tout cela se passe dans Samba et uniquement par Samba. Les ACL Posix sous Linux ne permettent pas ce genre de choses. Pour résumer, dans Samba, le groupe 512 peut modifier les ACL de tous les fichiers ce qui est une bonne chose.
    • [^] # Re: UP

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

      Je pense que ce n'est pas forcement le groupe 512 (Admins du domaine) mais tout les gens et groupes indiqués sur la ligne
      admin users = "@Mes admins"
      dans le smb.conf.
      • [^] # Re: UP

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

        Hello,

        vérification faite, c'est ça !!!

        Franchement, j'ai honte d'avoir remué tout un foin pour si peu.

        Merci à tous pour votre collaboration.

Suivre le flux des commentaires

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