Journal ACL : la solution pour les media de transport de données en Ext2+, ReiserFS, XFS…

Posté par  (site web personnel) .
Étiquettes : aucune
32
23
juil.
2009
Cher nourjal,

Je suis sûr que tu t'es souvent demandé comment formater tes media de transport (clefs et disques durs USB, IEEE 1394 ou eSATA). En FAT ? Non, c'est vieux et pourri, la FAT. En NTFS ? Pas question, c'est un format fermé.

En Ext2 alors ? Ben, oui, mais si je donne ce medium à un ami qui n'a pas le même UID que moi, il n'aura pas le droit d'écrire dedans… Problème insoluble ? Heureusement, non, grâce aux… ACL, les listes de contrôle d'accès !

Le but des ACL POSIX.1e, c'est d'aller plus loin que les simples permissions POSIX.1, en proposant notamment des droits relatifs à un UID ou à un GID donné. Mais pas seulement : il est également possible de préciser des ACL par défaut, qui s'applique aux nouveaux fichiers et répertoires créés sous un répertoire.

En pratique :
$ ls -l /dev/clef*
brw-rw---- 1 root floppy 8, 80 jui 22 22:05 /dev/clef
brw-rw---- 1 root floppy 8, 81 jui 22 22:05 /dev/clef1
$ mkfs.ext2 -L 'Gérard Bouchard' /dev/clef1              # formatage
$ tune2fs -o +acl /dev/clef1                             # option de montage par défaut

$ pmount /dev/clef1                                    # montage, ou alors avec GNOME ou KDE ou autre
$ cat /proc/mounts
/dev/clef1 /media/clef1 ext2 rw,nosuid,nodev,errors=continue,acl 0 0

$ setfacl -m user::rwx /media/clef1
$ setfacl -m group::rwx /media/clef1
$ setfacl -m other::rwx /media/clef1
$ setfacl -m default:user::rwx /media/clef1
$ setfacl -m default:group::rwx /media/clef1
$ setfacl -m default:other::rwx /media/clef1


Vérifions :
$ ls -ld /media/clef1
drwxrwxrwx+ 5 gerard gerard 4,0K jui 22 22:08 /media/

$ getfacl /media/clef1
# file: media/clef1
# owner: gerard
# group: gerard
user::rwx
group::rwx
other::rwx
default:user::rwx
default:group::rwx
default:other::rwx


Testons :
$ mkdir /media/clef1/test
$ ls -ld /media/clef1/test
drwxrwxrwx+ 2 gerard gerard 4,0K jui 22 22:08 /media/clef1/test/

$ getfacl /media/clef1/test
# file: media/clef1/test
# owner: gerard
# group: gerard
user::rwx
group::rwx
other::rwx
default:user::rwx
default:group::rwx
default:other::rwx

$ touch /media/clef1/test/pouet
$ ls -l /media/clef1/test/pouet
-rw-rw-rw- 1 gerard gerard 0 jui 22 22:08 /media/clef1/test/pouet


Vous pouvez faire le test avec un autre utilisateur : c'est bon, ces fichiers n'ont pas aucune permissions comme avec FAT qui en émule, mais ils ont tous les droits pour tout le monde. Dansez de joie, vous pouvez maintenant utiliser Ext2 pour vos clefs USB.
  • # Plus d'informations sur les ACL

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

    Si vous voulez en savoir plus sur les ACL, outre getfacl(1), setfacl(1) et acl(5), vous avez http://www.suse.de/~agruen/acl/linux-acls/online/ .
  • # Pour les râleurs

    Posté par  . Évalué à 2.

    Très bon journal, il va falloir que je me fasse une partition ext2/3 sur ma clef (et une petite partition en fat pour pouvoir lire ext2/3 depuis Windows).

    Et pour ceux qui penseraient que ce journal devrait se trouver dans les astuces, il répond à plusieurs questions dans le forum qui n'avait pas encore trouvé de réponse (ou pas assez précise).

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Pour les râleurs

      Posté par  . Évalué à 2.

      Ah ouai?
      Et pourquoi t'as pas mis ça en astuce et répondu aux questions sur le forum avec un lien vers l'astuce alors?
      Après tu pouvais faire un vrai journal:
      "Cher journal,
      J'ai pensé que ça pourrait t'intéresser:
      {là tu mets le lien vers l'astuce aussi}"

      -------------->[ ]
      • [^] # Re: Pour les râleurs

        Posté par  . Évalué à 3.

        Et pourquoi t'as pas mis ça en astuce

        Parce que c'est pas moi qui ait posté le journal et que vu la fréquence de question, elle intéresse un plus grand public que celui qui visite la catégorie astuce.

        répondu aux questions sur le forum avec un lien vers l'astuce alors?

        Parce que l'auteur du journal a déjà mis le lien dans les question du forum.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Ext2+ uniquement…

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

    À ma connaissance, cette solution ne marche complètement qu'avec Ext2+, parce que c'est le seul système de fichiers à proposer de régler des options de montage par défaut.
  • # Question

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

    Tout d'abord merci pour ce super journal.

    Petite question: est-ce que ça marche aussi quand on copie ou quand on déplace des fichiers sur le média externe, au lieu de les créer? Y compris quand on copie une arborescence toute entière? De mémoire c'est pour ce genre de choses que j'avais eu des problèmes.
    • [^] # Re: Question

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

      M'étonnerait… Désolé.
      • [^] # Re: Question

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

        Donc au final les ACL ne sont pas la solution non plus?
        • [^] # Re: Question

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

          Pas une solution complète, mais ça répond quand même à l'essentiel des problèmes.
          • [^] # Re: Question

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

            Ben justement, sur un disque dur externe, la plupart du temps, on ne fait que copier des fichiers, de manière à les faire transiter entre différents PC ou pour faire des sauvegardes. Je connais peu de personnes qui créent des fichiers directement sur ce genre de média.

            Vu que la question se pose régulièrement et que personne n'a su me donner une réponse complète, j'aimerais bien demander aux spécialistes des systèmes de fichiers de ce qu'ils penseraient d'une option "noperms", ou si il auraient une meilleure solution. Est-ce que quelqu'un qui a l'habitude du développement du noyau linux pourrait me dire où poser la question?
            • [^] # Re: Question

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

              La plupart du temps, on copie des documents, mais pour les placer dans un répertoire existant de la clef, donc ça laisse à tout le monde le droit de l'effacer.
  • # chmod

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

    Je comprend pas bien l'intérêt des ACL dans ce cas. C'est se compliquer la vie pour rien étant donné que les droits Unix traditionnels permettent de faire la même chose.

    Par contre, quand on n'est pas root et qu'on veut partager certains répertoires avec certains utilisateurs, c'est pratique. J'utilisais beaucoup cette technique pour le SVN des projets de groupe à l'unif.

    Par ailleurs, pour la petite histoire, les ACL POSIX ne sont pas vraiment POSIX. Il s'agit d'un brouillon qui a été abandonné bien qu'implémenté dans Linux et d'autre Unices.
    http://wt.xpilot.org/publications/posix.1e/download.html

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

    • [^] # Re: chmod

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

      Sans les ACL tu peux mettre des permissions par défaut ? C'est à dire l'équivalent d'un umode mais sans que le programme ait son avis sur la question ('fin ca doit être outrepassable)
      • [^] # Re: chmod

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

        g+s ? Ou bien j'ai pas compris la question.

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

        • [^] # Re: chmod

          Posté par  . Évalué à 5.

          Ça c'est uniquement pour que le groupe soit hérité, ça n'impose pas les permissions des nouveaux fichiers.
    • [^] # Re: chmod

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

      les droits Unix traditionnels permettent de faire la même chose

      Non. En regardant le but principal des ACL, les droits nommés, voici un exemple qui est irréalisable avec les droits traditionnels :

      # owner: gerard
      # group: gerard
      user::rwx
      group::rwx
      other::r--
      group:adm:r-x
      • [^] # Re: chmod

        Posté par  . Évalué à 2.

        sauf qu'en l'occurence ton groupe Gerard ne sert à rien (ou alors je suis curieux que tu m'expliques à quoi), donc tu aurais très bien pu utiliser le groupe adm.

        C'est bien les ACL comme tous les outils évolués, il ne faut pas en abuser (le rouleau compresseur et la pate à tarte quoi)
        • [^] # Re: chmod

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

          ou alors je suis curieux que tu m'expliques à quoi

          À ce que ses membres puissent modifier le fichier. Oui, je sais, le nom du groupe est un très mauvais exemple, mais enfin, c'est un cas où on ne peut pas faire la même chose à coup de permissions traditionnelles.
        • [^] # Re: chmod

          Posté par  . Évalué à 2.

          Il set à permettre aux utilisateurs du groupe gerard d'avoir les mêmes accès que l'utilisateur gerard. (Sous Ubuntu, les nouveaux utilisateur font partie par défaut du groupe du premier utilisateur créé il me semble).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Prise de tête inutile

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

    Si tu distribues tes fichiers sur un support externe, tu les met en accès monde (755, 644, voire 777, 666) et puis voilà, problème réglé.

    De toute façon, si ton support tombe dans des mains ennemies, il va être monté par un utilisateur root qui lira tous les fichiers, quelles que soient les permissions ou les ACL que tu t'es inutilement pris la tête à régler aux petits oignons.

    Si tu ne veux pas que tes données soient lues par des ennemis potentiels quand tu distribues un support externe, la solution c'est pas les permissions ou les ACL, c'est le chiffrement !
    • [^] # Re: Prise de tête inutile

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

      problème réglé

      Non, parce qu'il faut penser à le faire pour chaque fichier placé sur ce medium. C'est là l'intérêt des ACL par défaut.

      De toute façon, si ton support tombe dans des mains ennemies, il va être monté par un utilisateur root qui lira tous les fichiers, quelles que soient les permissions ou les ACL que tu t'es inutilement pris la tête à régler aux petits oignons.

      Si tu ne veux pas que tes données soient lues par des ennemis potentiels quand tu distribues un support externe, la solution c'est pas les permissions ou les ACL, c'est le chiffrement !


      Tu as mal compris mon but, qui n'est pas de protéger mes données contre la lecture mais de permettre à tout le monde des les lire et des les écrire.
    • [^] # Re: Prise de tête inutile

      Posté par  . Évalué à 1.

      "mains ennemies" ça fait très chinois du FBI...
    • [^] # Re: Prise de tête inutile

      Posté par  . Évalué à 3.

      comme il avait été dit dans le forum concerné, cette solution est valable uniquement pour des fichiers existants, pas pour les nouveaux créés ensuite.

      http://linuxfr.org/comments/1051557.html#1051557

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Prise de tête inutile

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

        Deux solutions alternatives :

        - umask 0
        - chmod -R 666

        Elles ne sont pas équivalents à la solution par ACL, mais elles ont l'avantage de marcher sur la plupart des Unix, avec la plupart des systèmes de fichiers, là où la solution par ACL est déjà nettement plus spécifique (est-ce que toutes les distributions les supportent bien d'ailleurs ?)
  • # Moi pas comprendre

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

    Salut,

    Après l'affaire Tomtom et les problèmes FAT, j'ai cherche un système de fichier qui serait libre et intégré à Linux (qui en supporte un chiée), mais je n'ai pas trouve mon bonheur. Ce qu'on recherche est un système de fichier tout simple sans support des droits Unix.

    J'ai lu a différents endroits (ne me demandez pas ou) qu'il y avait plusieurs systèmes de fichiers de ce type plus robustes que vfat dans le noyau, mais je ne les ai pas trouve. Est-ce que quelqu'un pourrait dire s'il en connaît? Ça serait tout de même plus simple que de se prendre le chou avec des droits et des ACL.

    Merki.
  • # Pas mal mais ...

    Posté par  . Évalué à 1.

    Dans mon expérience les ACL ne sont pas toujours respectées (cf https://linuxfr.org//~jadfa/27432.html).


    PS: pour les intéressés, concernant le répertoire réellement commun, la seule solution que j'ai trouvée est le partage samba
  • # Mouais

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

    Le problème, c'est quand même que ça ne va fonctionner que sous Linux, tout ça. FreeBSD et Windows ne comprendront pas les ACL, OS X non plus (et là ça va déjà être la galère rien que pour monter le système de fichiers en lecture-écriture).

    C'est triste, mais les systèmes de fichiers les plus adaptés au niveau interopérabilité aujourd'hui sont clairement le VFAT et le NTFS. Ce sont mêmes les seuls choix possibles, malheureusement.
    • [^] # Re: Mouais

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

      Windows, pas la peine de s'embêter, il ne prend en charge que deux systèmes de fichiers, donc si on veut causer avec, il n'y a pas le choix. Pareil pour MacOS X.

      On parle de choisir un système de fichiers pour porter des documents entre des systèmes d'exploitations complets, là. Windows et MacOS X, ce n'est pas du tout le sujet de mon journal.

      FreeBSD… bah au moins il comprendra les droits d'accès, qui lui apparaîtront en 777, c'est déjà ça. Ma solution d'ACL n'utilise que des droits habituels et des ACL par défaut.
      • [^] # Re: Mouais

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

        Windows supporte très bien l'ext2 avec un driver libre, OS X le supporte aussi avec MacFuse, mais en lecture-seule.

        Je n'ai pas envie de rentrer dans ton troll "systèmes d'exploitation complets", ce sont deux systèmes qui ont tous les deux leurs qualités qu'on le veuille ou non, et qui sont assez répandus pour pouvoir avoir besoin de partager des données avec eux, maintenant si tu cherches à ne pas pouvoir utiliser tes données sur 95% des ordinateurs, libre à toi d'utiliser de l'ext2, ça n'en rend pas mon commentaire moins valide pour autant.
        • [^] # Re: Mouais

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

          Ils le prennent en charge, oui, mais pas nativement. Ces deux systèmes sont extrèmement limités en termes de prise en charge des systèmes de fichiers. Quand on doit communiquer avec, il faut tenir compte de ces limitations, oui, mais ce n'est pas du tout le sujet de mon journal.
          • [^] # Re: Mouais

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

            Eh bien c'est le sujet de mon commentaire.

            Je n'ai pas vu de réponse du genre "oui mais Tomtom c'est pas un OS complet" au commentaire précédant le mien, qui pourtant a encore moins de rapport avec ton journal, n'est-ce pas ?
        • [^] # Re: Mouais

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

          Je n'ai pas envie de rentrer dans ton troll "systèmes d'exploitation complets",

          Mais c'est toi que le lance le troll! A aucun moment dans son journal Tanguy ne parle de compatibilité windows, c'est donc probablement qu'il s'en fout, non?

          Si ça ne te convient pas, parfait, mais ne vient pas commenter pour après l'accuser de lancer des trolls que tu as introduit toi-même.
          • [^] # Re: Mouais

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

            Pas du tout, je voulais juste préciser que ce n'était pas compatible avec FreeBSD, et je me suis dit tant que j'y étais que j'allais aussi parler des autres OS que je connais, je ne vois pas en quoi j'ai lancé un quelconque troll !

            Mais où va-t-on, j'ai tout de même bien le droit de parler de compatibilité avec d'autres OS dans un simple commentaire, n'est-ce pas ?!
        • [^] # Re: Mouais

          Posté par  . Évalué à 2.

          Moué, il paraît que Windows supporte bien l'ext2... Perso, j'arrive à le faire pour un disque directement formatté en ext3, mais pas depuis un disque chiffré en LUKS puis formatté en ext3.

          Avec FreeOTFE, je peux ouvrir le volume chiffré, mais au-delà, pas moyen de faire comprendre à Windows que le disque qui vient d'apparaître est en ext3... Et j'ai testé avec XP et Vista.

          Vu que tous mes disques sont chiffrés, pour moi, ça revient à dire que non, Windows ne supporte pas l'ext3.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Mouais

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

        ??? FreeBSD supporte les ACL !

        Ceci dit, je n'ai pas testé sur un support en ext2, mais au bug près, il n'y a pas de raisons.
    • [^] # Re: Mouais

      Posté par  (Mastodon) . Évalué à 3.

      il y'a des drivers ext2 pour windows et Mac OS X hein.
  • # Problème de droits ? Non, de fs

    Posté par  . Évalué à 3.

    De toute façon, je ne suis pas sûr qu'ext2/3 soit particulièrement conçu pour allonger la durée de vie des clefs usb, avec sa journalisation et toutes ses features très confortables pour un disque dur, il aurait plutôt tendance à raccourcir la vie de ta clef usb.

Suivre le flux des commentaires

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