Journal Respect des acl et KDE

Posté par  .
Étiquettes : aucune
2
2
nov.
2008
Depuis mon passage sous Linux (Mandriva pour être précis) je sèche sur un point: le répertoire commun à tous les utilisateurs.
Dernière version essayée: http://linux.jpvweb.com/mesrecetteslinux/commun_utilisateur
Donc avec les acl, tout est tout beau sauf ... avec les applications KDE (entre autre).
Par exemple: les photos éditées avec Digikam (excellent soft au demeurant) et "sauvegardées sous" ne respectent pas les acl ... mais le umask.
Ca m'énerve prodigieusement d'autant que je ne vois pas de solution . Et vous ?
  • # Partager un ordinateur

    Posté par  . Évalué à 7.

    Pour moi, c'est un des gros problèmes sous Linux. La gestion multi-utilisateur est tellement bien faite, que finalement, ça devient compliqué de partager des données.

    Ce qui manque (et je pense pourrait être facilement intégrable à un système de fichier), c'est un attribut permettant de supprimer toute permission à un fichier si il est dans un dossier donné.

    il existe bien l'attribut g+t me semble-t-il qui permet de mettre à un groupe précis tout les nouveaux fichiers créé dedans.
    Mais il faut déjà faire changer l'umask, classiquement mit à 022 (pour une raison que j'ignore) en 002, ce qui parfois pose problème (ce fut le cas il fut un temps sous Ubuntu) à cause de je ne sais quel dossier qui était par défaut créer avec de mauvaises permission, mais le plus gros problème vient du déplacement de fichier dans un tel répertoire, où là, tout les attributs de bases sont préservées (groupe et permission).

    Je n'ai à ce jour trouvé aucune solution satisfaisante.
    Les ACLs, le permettent peut-être, mais ça demande dans ce cas à être bien mieux implémenté (surtout au niveau des interfaces) pour mettre ça en place.

    Et il ne me semble pas avoir de système de fichiers libres (merci de le signaler si il y a) ne gérant pas les permissions (ce qui est quand même plus pratique pour un périphérique amovible. Résultat, pour les clefs et tout, même pour une utilisation 100% Linux, il demeure plus pratique d'utiliser du FAT…
  • # ACL roxor !

    Posté par  . Évalué à 7.

    En principe, avec les ACL, tu ne devrais pas avoir de problème :

    deux règles à placer, du type :
    setfacl -R g:usergroup:rwx
    ET
    setfacl -R d:g:usergroup:rwx
    devraient garantir ta tranquillité.

    Si c'est ce que tu avais mis en place, cela signifie que les applis KDE créent les fichiers dans un dossier temporaire, et les déplacent ensuite. Et là, c'est le drame. Plusieurs solutions possibles : placer le dossier temporaire en question sur une autre partition, ou (gruiiiiik) installer un soft de supervision de dossier qui changera les droits quand nécessaire.
    • [^] # Re: ACL roxor !

      Posté par  . Évalué à 9.

      Et troisième solution, signaler le bug sur bugs.kde.org. C'est quand même mieux de corriger KDE que de contourner le problème.
      • [^] # Re: ACL roxor !

        Posté par  . Évalué à 2.

        Oui j'y ai bien pensé mais en fait, après lecture des bugs similaires, ce n'est pas considéré comme un bug par KDE. C'est le mode de fonctionnement normal semble t'il.
    • [^] # Re: ACL roxor !

      Posté par  . Évalué à 1.

      A creuser en effet. Je n'avais pas pensé à modifier ce répertoire temporaire ... si j'arrive à le faire.
      Je vous tiens au courant !!
  • # Groupes?

    Posté par  . Évalué à 4.

    J'ai l'impression que tu fais trop compliqué.
    Si tu veux simplement un répertoire dont le contenu est accessible à tout le monde la gestion classique des groupes Unix est suffisante.

    Tu crée un groupe dans lequel tu met tous tes utilisateurs, tu crée ton répertoire et tu le place dans ce groupe avec les droits d'écriture au groupe et tu positionne le bit SGID du répertoire, ce qui aura pour effet que les fichiers créés dans le répertoire appartiendront aussi au groupe. Enfin, tu positionne pour tous les utilisateurs le umask pour qu'à la création il y aie le droit d'écriture au groupe.

    J'ai déjà utilisé ça et ça fonctionne correctement, à condition de ne pas utiliser des programmes qui forcent les permissions à autre chose que les valeurs par défaut (j'ai eu le cas avec des clients (S)FTP) (par contre, s'il y a partage samba en plus c'est un peu plus compliqué)
    • [^] # Re: Groupes?

      Posté par  . Évalué à 2.

      Oui mais si on ne veut pas que le umask soit comme ça partout, comment on fait ?

      Ce qui est bien dans les solutions proposées ici (celles avec les ACLs) c'est que c'est un peu comme si on changeait le umask par répertoire.
    • [^] # Re: Groupes?

      Posté par  . Évalué à 4.

      J'ai l'impression que tu fais trop compliqué

      Tu crée un groupe dans lequel tu met tous tes utilisateurs, tu crée ton répertoire et tu le place dans ce groupe avec les droits d'écriture au groupe et tu positionne le bit SGID du répertoire, ce qui aura pour effet que les fichiers créés dans le répertoire appartiendront aussi au groupe. Enfin, tu positionne pour tous les utilisateurs le umask pour qu'à la création il y aie le droit d'écriture au groupe.

      Aller exceptionnellement je me permets: mais LOL !

      Non seulement ta solution n'a vraiment rien de simple mais en plus elle implique la configuration d'une variable globale (umask) pour pouvoir gérer correctement les besoins d'un seul répertoire. Sa solution est beaucoup plus simple (un seul setfacl à faire) et répond parfaitement au besoin.

      C'est un problème très connu des droits UNIX, qui se rencontre dès que l'on veut partager des fichiers avec des gens (site web, données d'expérimentations, P2P etc.) et les ACL sont la seule réponse raisonnable. Après le problème est que les GUI gèrent très mal les ACL et qu'en général les montages réseaux ne les supportent pas.
      • [^] # Re: Groupes?

        Posté par  . Évalué à 2.

        gèrent très mal les ACL et qu'en général les montages réseaux ne les supportent pas.

        Samba doit gérer ça non ? NFS, FTP et consors, sans doute pas effectivement. Les gestionnaires de fichiers Linux pas bien non plus j'ai l'impression ...

        Après sous windows de mon expérience c'est pas complètement évident non plus si tu connais pas bien et si tu sais pas exactement ce que tu fais. Par contre je crois que eux ils ont des trucs "simplifiés" pour le novice, genre "autoriser pour tout le monde" dans une case à cocher en cachant la gestion ACL proprement dite.
        • [^] # Re: Groupes?

          Posté par  . Évalué à 2.

          Pour Samba c'est possible. C'est aussi possible en NFSv4 (en v3 ca reste parfois possible mais propriétaire). Cela dit j'ai pas l'impression que le déploiement d'NFSv4 soit encore très important. Pour le reste c'est totalement aléatoire.

          La situation n'a pas beaucoup évoluée depuis 2002... C'est la seule solution propre et viable à pas mal de problèmes (non faire tourner des chmod/chgroup en cron root n'est pas une solution). Après les ACL sont complexes à gérer et comprendre car tout les répertoires parents peuvent modifier les permissions obtenues. On peut facilement faire des trucs super compliqués. Mais la majorité des gens veulent faire des trucs super simples qu'il n'est pas possible de faire avec les permissions de base, et avec une GUI correct ça reste humain.
          • [^] # Re: Groupes?

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

            Tu peux aussi utiliser un FTP local pour gérer ton partage. Ça ne consomme pas tant de ressources et l'accès peut-être rendu transparent sous KDE, Gnome, etc.
            Avantage: on peut déplacer des fichiers ou dossiers dans le répertoire partagé, les droits d'accès seront ceux du ftp.
            A ma connaissance, la solution d'un serveur (ftp, samba, ...) reste la plus simple pour les utilisateurs.

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: Groupes?

              Posté par  . Évalué à 1.

              Ça me plait bien aussi comme solution, même si c'est un peu dommage d'utiliser un serveur sans passer par le réseau. CQFD (X, toussa, ...).
              Si je ne trouve pas le répertoire temporaire KDE, je tente le coup en partageant avec Samba (qui tourne déjà pour partager un autre répertoire avec un PC Windows).
            • [^] # Re: Groupes?

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

              Je me complète en ajoutant NFS, WebDAV, ... en gros toute solution serveur dont les droits d'accès peuvent être définis séparément (sans tenir compte des droits habituels) fonctionne bien, est facile d'emploi (pour les utilisateurs) et n'est pas trop emmerdante à administrer.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Mais pourquoi ça marche pas ?

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

    Bonjour,

    Je connaissais pas du tout les ACL, maintenant je me sens moins con (-: Je le serai encore moins le jour où je le mettrai en oeuvre !

    Cela dit, je comprends pas pourquoi ça marche pas. Tu dis "les applis KDE le gèrent mal", or si j'ai bien compris c'est au niveau OS (ou plus précisément File SYstem) que ça fonctionne, donc je vois pas en quoi l'appli doit etre "compatible"...

    Qqu'un peut expliquer ??? Merci (-:

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # acl et outils

    Posté par  . Évalué à 6.

    Un petit retour d'expérience d'un administrateur de parc en multi-utilisateur : (home dir sous NFS) :
    _ en NFSv3 les acl posix marchent très bien (testé : serveur solaris9 et linux, clients solaris9 et linux)
    _ EICIEL est une interface graphique à la gestion d'acl intégrée dans Nautilus (gestionnaire de fichier graphique de gnome)
    _ les acl posix et samba, en théorie ça marche, en pratique ...
    _ NFSv4 : le système d'ACL est un sur ensemble des acl posix et des acl windows, pas encore super intégré dans les distributions.
    _ les utilisateurs ne comprennent pas grand chose aux acl
    _ la notion de masque dans les acl est difficile à expliquer (similaire au umask)

    La page officielle de Eiciel : http://rofi.roger-ferrer.org/eiciel/
  • # Ma solution

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

    C'est rigolo, j'ai mis ma solution, à base de stiky bit en ligne hier :

    http://jeanuel.info/spip.php?article67

    Ça vaut ce que ça vaut.

Suivre le flux des commentaires

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