Forum Linux.général ACLs à la Windows

Posté par  .
Étiquettes : aucune
5
28
juin
2010
J'ai un rêve depuis pas mal d'années: avoir des ACLs sous Linux aussi bonnes que sous Windows (oui, les ACLs NTFS de Windows sont presques très bien, pas celle de Linux, loin de là).

Aujourd'hui encore je tombe sur un cas qui fonctionne parfaitement bien avec Windows, facilement, toussa. Et impossible d'avoir à peu près la même chose sous Linux.

J'écris cela ici dans l'espoir que je sois juste un gros mauvais, et qu'on me clou le bec en me disant "il suffit de taper setfacl xxxxxx toto titi". Je serais bien content de constater être un gros nul, si vous saviez comme ça me faciliterait le travail :-)

Assez palabré, voici le cas:

répertoire--+
............|
............+---
  • # Zut, j'ai validé... :-)

    Posté par  . Évalué à 4.


    répertoire--+
    ............|
    ............+---utilisateur1
    ............|
    ............+---utilisateur2
    ............|
    ............+---groupe1
    ............|
    ............+---groupe2


    "répertoire" est accessible en lecture/écriture/modification par tous les utilisateurs (ici via Samba).
    Chaque sous répertoire est protégé. Par exemple "utilisateur1" n'est accessible qu'à, devinez, l'utilisateur nommé utilisateur1.
    "groupe1" n'est accessible qu'à une liste de personne.

    Jusque là c'est facile. Il suffit d'utiliser setfacl ou smbcacls pour ajouter des droits.

    Avec Windows, il est possible de supprimer explicitement des droits. Par exemple j'indique que "tout le monde" n'a pas le droit de supprime le répertoire "utilisateur1". Sous Linux, pas possible.
    Ce qui fait que n'importe qui pouvant modifier "répertoire" est également capable d'effacer les sous-répertoires.

    Je sais d'avance que certains vont répondre "y'a qu'à interdire l'écriture dans le répertoire de base". Ce qui complique beaucoup la tâche pour les utilisateurs qui veulent par exemple bosser à plusieurs dans "compta" _et_ avoir certains sous-répertoires confidentiels, ou simplement protégés contre les erreurs. Si ils ne peuvent pas le faire ainsi, c'est à l'administrateur de créer à chaque fois un répertoire à partir de la racine du partage.


    D'où question: une astuce pour contourner cette limitation ?
    • [^] # Re: Zut, j'ai validé... :-)

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

      C'est la même que pour /tmp, pour permettre à tout le monde de créer des fichiers mais interdire à utilisateur1 de supprimer les fichiers d'utilisateur2.

      In addition to the three sets of three permissions listed above, a
      file's permissions have three special components, which affect only
      executable files (programs) and, on some systems, directories:


      [...]

      3. prevent users from removing or renaming a file in a directory
      unless they own the file or the directory; this is called the
      "restricted deletion flag" for the directory. For regular files
      on some systems, save the program's text image on the swap device
      so it will load more quickly when run; this is called the "sticky
      bit".
      • [^] # Re: Zut, j'ai validé... :-)

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

        Ah, j'allais oublier :

        Tu es juste un gros mauvais. Il suffit de taper chmod 04777 comp/. Gros nul, on te facilite le travail !

        :-)
        • [^] # Re: Zut, j'ai validé... :-)

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

          N'importe quoi.

          1. Les permissions, c'est sur 4 chiffres octaux, pas 5.

          2. Le sticky bit, c'est 1 sur le premier chiffre, pas 4.

          Donc plutôt :
          chmod 1777 comp/
          Ou plus exactement, pour éviter de toucher aux permissions existantes :
          chmod +t comp
          • [^] # Re: Zut, j'ai validé... :-)

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

            1. Les permissions, c'est sur 4 chiffres octaux, pas 5.

            Le premier zéro est le préfixe usuel pour indiquer les nombres en base 8. Inutile pour l'argument à chmod, c'est vrai, mais par habitude...

            Le sticky bit, c'est 1 sur le premier chiffre, pas 4.

            Autant pour moi, je me suis fait avoir par la position du sticky bit dans la liste, je les croyais rangé par ordre de puissance de 2, sans avoir vérifié. L'écriture symbolique est aussi simple.
            • [^] # Re: Zut, j'ai validé... :-)

              Posté par  . Évalué à 4.

              Autant pour moi, je me suis fait avoir par la position du sticky bit dans la liste,

              « Au temps pour moi ».

              Mais c'est vrai que je me suis souvent trompé de chiffre pour le sticky, moi aussi.
        • [^] # Re: Zut, j'ai validé... :-)

          Posté par  . Évalué à 3.

          Hélas non, ça ne fonctionne que dans les cas basiques. Il n'est pas possible de dire que "compta" est accessible par toutes les personnes de la comptabilité, mais que "compta/planning" n'est accessible en écriture et suppression qu'à Toto et Titi (nos employés ont des prénoms étranges).
          • [^] # Re: Zut, j'ai validé... :-)

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

            Il y a une contradiction dans ton cas.

            1. Tu veux que tes utilisateurs puissent créer des fichiers (en l'occurrence, des répertoires) eux-mêmes, sans te demander. Donc un répertoire racine où ils peuvent écrire.

            2. Tu veux que n'importe quel utilisateur ne puisse pas retirer un fichier d'un autre (en l'occurrence, un répertoire). Donc un répertoire racine sticky.

            3. Tu veux que tes utilisateurs puissent créer des sous-répertoires avec une liste précise de gens ayant le droit de faire ceci ou cela. C'est là que ça coince, parce que ça contredit le point 1 : ce sont des utilisateurs, et ça, ils ne le feront pas eux-mêmes. Ils te demanderont de le créer, le répertoire de la mort.

            Donc, mon conseil : réfléchis à ton besoin. Si tu as un répertoire /compta (je compte à partir de la racine du partage), écrire dedans, cela signifie organiser le classement même des données de la compta : c'est un droit qui devrait revenir aux chefs de la compta. Si tu as un répertoire /compta/planning, écrire dedans signifie organiser le planning de la compta, à toi de voir qui est censé le faire. Mais quelqu'un qui a le droit d'organiser le classement de la compta pourra supprimer ce répertoire (s'il est vide), ou le renommer : c'est fort logique, puisqu'il est gestionnaire du classement de la compta…

            À retenir, d'une façon générale : les droits (lecture, écriture, exécution) s'appliquent au fichier sur lequel ils sont définis, en tant que données (pour un répertoire, en tant que liste de liens nommés vers des fichiers). Pas au lien, c'est à dire au nom que ce fichier porte dans un ou plusieurs répertoires.
            • [^] # Re: Zut, j'ai validé... :-)

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

              Autre façon de voir les choses  : pense en terme de niveaux de répertoires et de délégation de pouvoir. Si dans la compte, une équipe (appelons-la planning), composée de Titi et de Toto, a besoin de stocker des données, elle va avoir besoin d'un répertoire et du droit d'écrire dedans. Ce droit va lui être attribué par une chaîne de délégation de droits, matérialisée par un chemin de répertoires : root a créé le partage réseau, des gens peuvent créer des répertoires dedans, en autorisent d'autre à créer des sous-répertoires, etc. L'existence et le nom de ce répertoire sont du ressort du niveau supérieur : cette équipe a son répertoire, et fait ce qu'elle veut dedans.
    • [^] # Sticky bit

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

      La « suppression » et la « création » de fichiers ne sont pas des droits. Les droits correspondants sont l'écriture dans le répertoire parent.

      Si j'ai bien compris, tu veux n'autoriser la suppression d'un fichier (en l'occurrence, un répertoire) que pour certaines personnes, qui doivent quand même pouvoir créer et supprimer des fichiers dans le répertoire parent.

      Oublions les ACL qui n'ont rien à faire ici : elles ne servent qu'à permettre des attributions plus fines des droits, et non des attributions de droits plus fins. On peut se contenter de parler de droits Unix classiques, tu adapteras selon la granularité à laquelle tu veux les accorder.

      Bref, ça se rapproche assez du cas typique d'utilisation du sticky bit, qui, sur un répertoire, permet de n'autoriser la suppression d'un fichier que par le propriétaire de ce fichier. Il est typiquement utilisé dans /tmp, afin que tout le monde puisse y créer des fichiers, mais que personne ne puisse supprimer les fichiers d'autrui :
      1777 /tmp
      Ou en symbolique, le « t » représentant le sticky bit :
      drwxrwxrwt /tmp
      • [^] # Re: Sticky bit

        Posté par  . Évalué à 3.

        Oublions les ACL qui n'ont rien à faire ici
        C'est ton point de vue. Pas le mien :-)
        Ce n'est pas celui de Novell (sur leurs ex-système) ni celui de Microsoft.

        Je me souviens toujours du système Novell Netware qui permettait même de supprimer l'administrateur des ACLs... Impossible de récupérer les droits avant je ne sais plus quelle version.
        • [^] # Re: Sticky bit

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

          Les ACL ne permettent pas d'attribuer des droits plus fins.

          Les ACL permettent d'affecter plus finement des droits classiques (lecture, écriture, exécution).

          Les attributs étendus permettent d'attribuer des droits plus fins.
    • [^] # Autre solution

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

      Autre solution : fais en sorte que tout le monde puisse écrire dans ton répertoire, mais s'ils veulent empêcher que quelqu'un d'autre enlève les répertoires qu'ils ont créés, qu'ils mettent des fichiers dedans.

      Parce que, quelque part, si quelqu'un crée un répertoire, mais ne met rien dedans, qu'est-ce que ça peut bien lui faire qu'on lui enlève ? Il n'y a pas de perte de données.

      En revanche, s'il y met quelque chose, seuls les gens qui ont le droit d'écrire dans son répertoire (et ça, c'est lui qui le gère) pourront supprimer ce quelque chose, ce qui est un pré-requis pour pouvoir retirer le répertoire (on ne retire pas un répertoire non vide).
  • # Sticky

    Posté par  . Évalué à 6.

    J'écris cela ici dans l'espoir que je sois juste un gros mauvais, et qu'on me clou le bec en me disant "il suffit de taper setfacl xxxxxx toto titi". Je serais bien content de constater être un gros nul, si vous saviez comme ça me faciliterait le travail :-)

    Même chose que tous les autres. Je pense que le sticky bit est ce que tu cherches. Donc, rien à ajouter. Cependant, je peux quand même te traiter de gros nul si ça peut te rendre service. :-)
    • [^] # Re: Sticky

      Posté par  . Évalué à 2.

      :-) Merci, mais non, ça ne fonctionne que pour un utilisateur unique, donc pas de sticky.

      J'ai vérifier sur un boî-boîte toute faite de chez D-Link, même chose.

Suivre le flux des commentaires

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