Forum Linux.général Problème de gestion des droits dans un dossier partagé local

Posté par  . Licence CC By‑SA.
Étiquettes :
1
28
août
2020

Bonjour,

Sur l'ordinateur familial (énergisé par Debian Buster), chaque membre de la famille possède un compte utilisateur. Je souhaite créer un dossier commun dans lequel tous les utilisateurs pourront ajouter/supprimer/lire les fichiers qui y sont stockés, indépendamment de leurs dossiers personnels respectifs. J'ai voulu essayer avec deux utilisateurs "papa" et "maman".

J'ai donc crée le dossier de partage :

mkdir -p /home/Dossier\ partagé/

Je crée un groupe "partage" :

groupadd partage

Auquel j'ajoute les utilisateurs :

usermod -a -G partage papa
usermod -a -G partage maman

Je change ensuite le groupe du dossier pour le groupe partage précédemment crée :

chgrp -R partage /home/Dossier\ partagé/

Et finalement je donne les permissions adéquates pour que root (propriétaire) et les membres du groupe partage puissent écrire, mais que les autres ne puissent pas y accéder :

chmod -R 2770 /home/Dossier\ partagé/

Le problème est que papa ne peut pas accéder à ce dossier partagé, bien que faisant partie du groupe "partage", alors que maman peut. Pourquoi donc ?

grep "papa" /etc/group
papa:x:1000:
partage:x:1002:papa,maman

grep "partage" /etc/group
partage:x:1002:papa,maman

Par ailleurs, quelles permissions dois-je mettre pour que les futurs fichiers copiés dans ce dossier puissent être lus/modifiés/supprimés par n'importe lequel des utilisateurs de ce groupe ?

Ce doit être un truc bateau, mais je suis passé à côté…

Merci d'avance pour votre aide.

  • # Pistes

    Posté par  . Évalué à 3.

    Pour papa, il devrait se reconnecter pour prendre en compte l'ajout du groupe.

    Pour la création de fichiers avec les bons droits, tu as visiblement défini le masque de création avec le 2 du chmod, donc je donne ma langue au chat.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Pistes

      Posté par  . Évalué à 3.

      Effectivement, c'était juste ça… je n'avais pas pensé à me déconnecter/reconnecter.
      Papa a maintenant les mêmes droits que Maman ! \o/
      Merci.

  • # ACL obligatoires ?

    Posté par  . Évalué à 5.

    Si papa ne peut pas accéder au dossier partagé, c'est peut-être parce qu'il n'appartenait pas encore au groupe partage au moment de son ouverture de session (en tout cas, je ne vois pas d'autre raison). Refais un test avec avoir fermé et re-ouvert la session de papa.

    Pour ce qui est des droits en écriture pour tous les membres du groupe, sur tous les fichiers du répertoire, je ne pense pas qu'il soit possible de faire ce que tu veux en utilisant uniquement les droits standard. Lorsque maman va créer un fichier dans le dossier partagé, son groupe sera bien partage mais il n'y aura pas les droits d'écriture pour les autres membres du groupe (sauf à modifier le masque de droits pas défaut mais c'est aléatoire et potentiellement dangereux).

    Mais il est peut-être possible de s'en sortir en utilisant les ACL (acess control list). Il faudrait essayer quelque chose dans ce genre :

    setfacl --default -m g:partage:rwx "Dossier partagé"

    Ensuite, les fichiers créés dans le dossier partagé seront bien autorisés en écritures pour les membres de partage.
    En revanche, c'est un peu plus compliqué pour les fichiers copiés ou déplacés dans le répertoire. Ils conservent les droits du fichier d'origine et je ne sais pas trop comment s'en sortir à ce niveau-là.

    Si quelqu'un sait comment faire, je suis aussi preneur.

    • [^] # Re: ACL obligatoires ?

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

      Note : Utiliser les ACL suppose d'installer le paquet acl2 et d'activer l'option sur le FS concerné.

      Debian Consultant @ DEBAMAX

    • [^] # Re: ACL obligatoires ?

      Posté par  . Évalué à 1.

      L'autre solution pourrait être de créer une partition à part, avec un système de fichiers qui ne gère pas les droits de fichiers (ceci n'est nullement à l'encontre du libre) ce qui aurait double avantage : pas de gestion de droit, place allouée fixe, empêchant un remplissage de disque inattendu.

    • [^] # Re: ACL obligatoires ?

      Posté par  . Évalué à 1.

      D'accord, merci, j'ai regardé du côté des ACL, ça me semble plus compliqué à gérer pour un besoin si basique.

      Je vais regarder tout bêtement du côté de la partition tierce d'AlexTerieur.
      Le format NTFS semble convenir pour cette tâche. À moins qu'un autre format soit plus approprié ?

      • [^] # Re: ACL obligatoires ?

        Posté par  . Évalué à 1. Dernière modification le 30 août 2020 à 17:25.

        Je n'ai jamais regardé, mais il me semble que le format ext(4) on peut désactiver la gestion des droits, par le biais d'options dans le fstab. A confirmer.
        Regarder aussi comment bien sécuriser le tout (je ne fais pas l'apologie de la désactivation de gestion de droit, bien au contraire).

  • # setGUID

    Posté par  . Évalué à 2.

    Le principe du setgid est le même que le setuid pour un fichier, mais bien entendu au niveau des droits du groupe. Un exécutable setgidé peut donc être lancé avec les droits du groupe auquel il appartient. Par contre, le comportement change lorsqu’il s’agit d’un répertoire. Lorsqu’un répertoire est setgidé, tous les fichiers créés dans ce répertoire appartiennent au même groupe que le répertoire. Ainsi, imaginons un répertoire conteneur, plusieurs personnes – Jean-Claude, André et Robert – travaillent dedans pour un même projet, il est bon de le setgider, de cette façon, les fichiers créés appartiendront tous au même groupe et non aux groupes de chaque utilisateur individuel.

    Source https://tech.feub.net/2008/03/setuid-setgid-et-sticky-bit/
    Et aussi
    https://fr.wikipedia.org/wiki/Setuid

  • # Commentaire supprimé

    Posté par  . Évalué à 0. Dernière modification le 10 septembre 2020 à 09:14.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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