[résolu] Monter 1 partition simultanèment dans divers dossiers ?

Coeur Noir · Le 05/04/2015, à 13:43

Hello, hello…

L'idée au final c'est que des utilisateurs différents [sur un même pc] accèdent en lecture/écriture à un même stockage de données [interne au pc], de façon transparente c'est à dire :

que sous les /home/user_x_y_ou_z/Documents apparaisse la même chose.

[en préalable : les utilisateurs qui ont cette partition en commun font partie d'un même groupe qui a les droits r+w]

Vaut-il mieux :
- dans le fstab, faire monter cette partition dans chaque /home/user_x_y_ou_z/Documents ?
- dans le fstab, monter cette partition uniquement dans /home/user_x/Documents et dans les /home/user_y_et_z remplacer Documents par un lien vers /home/user_x/Documents ?
- ne pas passer par fstab mais par …autre chose - quoi ?… qui ne monterait cette partition dans /home/user_x_y_ou_z/Documents qu'au moment de l'ouverture de session utilisateur - et non au démarrage système ?

Conseils et suggestions bienvenus !

Dernière modification par Coeur Noir (Le 07/06/2015, à 21:34)

sauthess · Le 05/04/2015, à 13:56

bonjour,

Pour les montage dynamiques à l'accès dans le répertoire, tu peux regarder autofs.

Concernant les montages multiples, tu peux regarder l'option --bind de mount qui permet de donner acces au meme montage depuis plusieurs répertoires différents. J'utilise cette possibilité pour partager un point de montage par différentes VM et cela marche très bien.

maxire · Le 05/04/2015, à 14:02

Salut,

Tout à fait possible, voici un exemple avec le répertoire ~/Musique décrit dans fstab:

# /data was on /dev/sda6
UUID=5c4ed4e6-d013-45fd-97d5-990d15b49873       /data                           ext4    defaults                0       2
#
/data/Musique                                   /home/user1/Musique      ext4    rbind,defaults          0       0
/data/Musique                                   /home/user2/Musique     ext4    rbind,defaults          0       0
/data/Musique                                   /srv/sftp/Musique               ext4    rbind,defaults          0       0

Le répertoire /srv/sftp/Musique est un serveur de musique accédé via sshfs.

Pour les autorisations d'accès:

$ ls -ld /data/Musique
drwxrwxr-x 209 musique musique 12288  2 avril 21:34 /data/Musique

Chaque utilisateur obtient l'autorisation d'écrire dans /data/Musique via une appartenance au groupe musique.
Ceci est à adapter en fonction de ton objectif.

Inconvénient, il faut ajouter une entrée dans fstab lors de la création d'un nouvel utilisateur, une alternative serait , d'utiliser un lien symbolique défini dans /etc/skel, si tu désires que tout nouvel utilisateur doit accéder à la partition, + paramétrer la création des utilisateurs pour que ceux-ci soient automatiquement attachés à un groupe qui va bien.

Coeur Noir · Le 05/04/2015, à 17:55

Intéressant.

C'est quoi la différence entre rbind et ça https://doc.ubuntu-fr.org/mount_fstab#m … ande_mount ?

Dans ce que tu montres, que se passe-t-il quand user1 ajoute des nouveaux fichiers dans /data/musique :
- propriétaire = user1 / groupe = musique
- ou musique / musique ?

Qu'est ce qui détermine le "propriétaire/groupe" de ce qui est dans /data/musique ?

maxire · Le 05/04/2015, à 18:54

Bonne question Cœur Noir,

rbind inclut les sous-montages contrairement à bind qui ne monte q'un seul système de fichiers.
Par exemple si dans l'arborescence de /data/Musique il existe un point de montage d'une autre partition, celui-ci sera pris en compte par rbind et non par bind.

Mon exemple ne correspond pas tout à fait à ce que tu recherches dans la mesure où dans ce cas les fichiers ne sont créés que par un utilisateur distant musique.
Les fichiers musicaux sont copiés à partir d'un lecteur de CD quelque part sur le réseau qui voit le répertoire /srv/sftp/Musique comme utilisateur musique groupe principal musique.
C'est l'utilisateur du serveur sftp qui crée les fichiers et cet utilisateur est justement musique.

Pour information voici la définition du serveur sftp dans sshd_config:

Subsystem       sftp    internal-sftp -u 0002

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server
Match User musique
        ChrootDirectory         /srv/sftp
        X11Forwarding           no
        AllowTcpForwarding      no
#       ForceCommand            internal-sftp
        PermitTunnel            no
        AuthorizedKeysFile      /etc/ssh/authorized_keys/musique/authorized_keys

Les fichiers sont propriétés des utilisateurs qui les créent et leurs groupes d'appartenance sont les groupe principaux des utilisateurs créateurs.

Dans ton cas, si tu désires autoriser les mises à jours des fichiers par d'autres utilisateurs, il faudrait que tous tes utilisateurs aient le même groupe principal, c'est d'ailleurs ce que fait OpenBSD (si je me souviens bien), tous les utilisateurs normaux (non système) ont pour groupe principal users.

À cette condition un fichier créé par user1 aura pour propriétaire user1 et comme groupe users.
Un fichier créé par user2 aura pour propriétaires user2 et comme groupe users.

L'autorisation d'accès de groupe devra être rw donc il faudra également définir un umask par défaut à 002 ce qui permet de créer des fichiers en 664 (rw,rw,r).
Ce masque par défaut peut se définir dans /etc/profile ou en ~/.profile en insérant la commande umask 002 dans un de ces fichiers (il existe également /etc/login.defs et /etc/bash.bashrc).

Il est également possible de définir des ACL (Access Control lists) pour un répertoire, c'est une fonction que je viens de découvrir et je ne suis pas certain d'avoir tout compris.

AlexandreP · Le 06/04/2015, à 01:38

maxire a écrit :

Dans ton cas, si tu désires autoriser les mises à jours des fichiers par d'autres utilisateurs, il faudrait que tous tes utilisateurs aient le même groupe principal, c'est d'ailleurs ce que fait OpenBSD (si je me souviens bien), tous les utilisateurs normaux (non système) ont pour groupe principal users.

L'autre possibilité, si le système de fichiers de destination gère les droits d'accès (ex: ext3, ext4, btrfs, Reiser4..., mais pas NTFS, extFAT ou FAT32), c'est d'utiliser une étiquette setgid sur le répertoire de destination pour en forcer l'attribution des nouveaux fichiers à un groupe bien précis.

Pour continuer avec l'exemple précédent: un système de fichiers ext4 monté en /data. Ce système de fichiers contient un dossier Musique/, dans lequel on souhaite que l'ensemble des nouveaux fichiers appartienne au groupe "musique". On procéderait ainsi:

sudo chgrp musique /data/Musique
sudo chmod g+s /data/Musique

Comme le changement s'appliquera à tous les nouveaux fichiers créés ou copiés dans le dossier, il pourrait être utile de refaire un tour de roue dans le dossier afin d'attribuer à nouveau la propriété des fichiers déjà présents dans le dossier au groupe "musique":

sudo chgrp -R musique /data/Musique

.

maxire a écrit :

Il est également possible de définir des ACL (Access Control lists) pour un répertoire, c'est une fonction que je viens de découvrir et je ne suis pas certain d'avoir tout compris.

Je dois avouer ne pas avoir beaucoup d'expérience avec les ACL moi non plus. Cependant, ce que j'en comprends, c'est que c'est surtout utile si on veut aller plus loin que donner des droits à un seul utilisateur ou à un seul groupe. Par exemple, on voudrait que tous les utilisateurs membres du groupe "musique" puisse lire (accès lecture seule) les morceaux du dossier /data/Musique/; mais on souhaiterait accorder à Alice et Bob la possibilité d'ajouter des nouvelles pistes (accès en lecture et écriture pour les usagers Alice et Bob uniquement).

MicP · Le 06/04/2015, à 07:06

Il y en a une autre : Diviser la partition NTFS existante en plusieurs partitions NTFS,
et il suffira de les faire mounter au démarrage par "/etc/fstab"
en leur donnant à chacune les "uid", "gid", "répertoire de mountage" spécifique à chacune dans "/etc/fstab".

maxire · Le 06/04/2015, à 09:15

@AlexandreP: setgid, je n'y avais pas pensé, il faut dire qu'à force de lire des affirmations du genre «le bit suid c'est le diable» j'ai tendance à me désintéresser à ce genre de solution et à mettre le bit sgid dans le même sac.
C'est sans doute mieux que de jouer avec le gid des utilisateurs comme je le propose
En ce qui concerne les ACLs il existe des limites d'utilisation notamment lors d'un copier/coller à partir d'un répertoire externe où la définition de l'ACL n'est pas prise en compte, documentation ACL disponible ici.
Je dirais que pour l'instant l'utilisation des ACLs est à éviter, à moins que le répertoire ne soit utilisé en silo isolé du reste des données.

@Micp: Dans le cas de NTFS, oui cela semble plus simple, personnellement j'évite d'utiliser NTFS pour une simple question de disponibilité des outils sous Linux (contrôle du système de fichiers, redimensionnement, déplacement, défragmentation).
Il faut dire que je n'utilise pas Windows en dual-boot, en cas de nécessité je partage les données entre machines linux/windows via sshfs, je suis devenu un «addict» de sshfs, à mon point de vue plus simple à configurer comparé à samba et nfs.
Ceci dit, il est vrai que Cœur Noir n'a pas précisé ce qu'il veut utiliser comme système de fichiers.

Coeur Noir · Le 06/04/2015, à 11:30

Bon d'abord merci et bravo à tous, car vos suggestions et réponses sont claires détaillées et argumentées, ça fait plaisir !

J'ai précisé qu'il s'agissait de plusieurs utilisateurs sur un seul pc - et aussi un seul OS : Ubuntu, ça ne coulait pas forcèment de source…

…donc pas de NTFS, n'ayant pas de ouinetruc sous la main s'il fallait réparer le système de fichiers.

Dernière modification par Coeur Noir (Le 06/04/2015, à 11:42)

maxire · Le 06/04/2015, à 12:13

Je viens de réaliser un test en couplant l'utilisation du bit sgid et la définition d'un masque par défaut via une ACL, je le livre tel quel:

[frankenstein@frankenstein ~]$ sudo useradd -m -d /var/lib/documents -r -s /bin/nologin documents
[sudo] password for frankenstein: 
[frankenstein@frankenstein ~]$ cat /etc/passwd | grep documents
documents:x:615:613::/var/lib/documents:/bin/nologin
[frankenstein@frankenstein ~]$ cat /etc/group | grep documents
documents:x:613:
[frankenstein@frankenstein ~]$ ls -ld /var/lib | grep documents
[frankenstein@frankenstein ~]$ ls -ld /var/lib/* | grep documents
drwx------  2 documents documents 4096  6 avril 11:44 /var/lib/documents
[frankenstein@frankenstein ~]$ sudo mkdir /documents
[frankenstein@frankenstein ~]$ sudo chown documents:documents /documents
[frankenstein@frankenstein ~]$ ls -ld /documents
drwxr-xr-x 2 documents documents 4096  6 avril 11:46 /documents
[frankenstein@frankenstein ~]$ sudo chmod g+ws /documents
[frankenstein@frankenstein ~]$ ls -ld /documents
drwxrwsr-x 2 documents documents 4096  6 avril 11:46 /documents
[frankenstein@frankenstein ~]$ whoami
frankenstein
[frankenstein@frankenstein ~]$ groups
sys adm disk lp wheel uucp log locate video audio floppy scanner users vboxusers frankenstein musique
[frankenstein@frankenstein ~]$ sudo usermod -G documents -a frankenstein
[frankenstein@frankenstein ~]$ exit
----- Déconnexion utilisateur ----
----- Reconnexion utilisateur ----
[frankenstein@frankenstein ~]$ whoami
frankenstein
[frankenstein@frankenstein ~]$ groups
sys adm disk lp wheel uucp log locate video audio floppy scanner users vboxusers documents frankenstein musique
[frankenstein@frankenstein ~]$ sudo setfacl --set d:m:rwx /documents
[sudo] password for frankenstein: 
[frankenstein@frankenstein ~]$ getfacl /documents
getfacl : suppression du premier « / » des noms de chemins absolus
# file: documents
# owner: documents
# group: documents
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

[frankenstein@frankenstein ~]$ touch /documents/test.txt
[frankenstein@frankenstein ~]$ ls -ld /documents/*
-rw-rw-r--+ 1 frankenstein documents 0  6 avril 11:52 /documents/test.txt
[frankenstein@frankenstein ~]$ getfacl /documents/test.txt
getfacl : suppression du premier « / » des noms de chemins absolus
# file: documents/test.txt
# owner: frankenstein
# group: documents
user::rw-
group::rwx			#effective:rw-
mask::rw-
other::r--

À méditer et à tester...

L'intérêt de créer un utilisateur système «documents» propriétaire du répertoire commun est de permettre simplement d'autoriser ou interdire l'accès en écriture à un utilisateur en l'attachant au groupe documents ou en le détachant, ceci sans considération de l'utilisateur. En clair les documents sont libres de droits, indépendants des utilisateurs normaux.
L'utilisateur retiré du groupe documents pourra toujours accéder en écriture aux fichiers dont il est le propriétaire pour autant que le répertoire /documents est en lecture pour tous.
En me relisant, je pense qu'il eût été mieux de faire un setfacl --set d:m:rw plutôt que setfacl --set d:m:rwx

Note: Voici un bon document expliquant le fonctionnement des ACLs Utiliser les ACLs dans Fedora

Dernière modification par maxire (Le 06/04/2015, à 14:40)

AlexandreP · Le 07/04/2015, à 03:26

maxire a écrit :

L'intérêt de créer un utilisateur système «documents» propriétaire du répertoire commun est de permettre simplement d'autoriser ou interdire l'accès en écriture à un utilisateur en l'attachant au groupe documents ou en le détachant, ceci sans considération de l'utilisateur.

Salut,

Je ne suis pas sûr de comprendre où tu veux en venir avec cette phrase. Parce que, si je lis bien l'exemple que tu donnes, tu ne fais jamais appel à un compte utilisateur système. Tu fais des références uniquement au groupe "documents", jamais à l'utilisateur "documents" (sauf pour lui donner la propriété du répertoire /documents). Tu aurais très bien pu:
- créer uniquement un groupe d'utilisateurs "documents", avec groupadd ou addgroup, et ajouter ton compte utilisateur dans ce groupe avec usermod comme tu l'as fait (ou avec adduser);
- ne pas créer de compte utilisateur "documents";
- laisser la propriété du répertoire à l'utilisateur root, mais -- comme tu l'as fait -- attribuer "documents" en tant que groupe propriétaire.

MicP · Le 07/04/2015, à 08:25

maxire a écrit :

…Dans le cas de NTFS, oui cela semble plus simple,…

Désolé : je parlais de NTFS, car je pensais qu'il s'agissait d'une partition formatée avec ce format (j'ai lu trop vite), mais la méthode de division de la partition afin de gérer plus finement les propriétaires, groupes, les droits d'accès et les privilèges fonctionnera aussi avec tous les types de système de fichiers, d'autant qu'avec des systèmes de fichiers sur LVM, c'est très facile d'agrandir, diminuer, faire des snapshots différentiels, mais bon : c'est peut-être pas là le problème…

maxire a écrit :

… personnellement j'évite d'utiliser NTFS…

Moi aussi : comme la peste, ne serait-ce que que pour la lenteur d'accès à ses fichiers, l'impossibilité de gérer ses droits et privilèges de façon "sécure", son jeu de caractère bâtard qui fout la pagaille dans les noms longs, et tout simplement le fait qu'il est fermé par des brevets.
Bon je m'arrête là, c'est pas bon pour ma santé.

Dernière modification par MicP (Le 08/04/2015, à 07:41)

Coeur Noir · Le 08/04/2015, à 17:06

Bon, après toutes ces précieuses informations et pour revenir un peu au sujet de départ :

- vous me confirmez qu'il n'y a pas de souci particulier au fait d'avoir une même partition montée dans plusieurs dossiers d'utilisateurs différents ? Notamment dans le cas, rare, où ces utilisateurs laisseraient leurs sessions ouvertes, en même temps ?

AlexandreP · Le 11/04/2015, à 05:30

Coeur Noir a écrit :

- vous me confirmez qu'il n'y a pas de souci particulier au fait d'avoir une même partition montée dans plusieurs dossiers d'utilisateurs différents ? Notamment dans le cas, rare, où ces utilisateurs laisseraient leurs sessions ouvertes, en même temps ?

Non, il n'y a pas de problème en ce qui concerne le montage d'un volume monté en plusieurs points de montage.

Il n'y a pas non plus de souci en ce qui concerne les multiples sessions simultanément ouvertes -- le volume reste monté jusqu'à ce que quelqu'un démonte le volume, ce qui devrait normalement nécessiter le droit super-utilisateur si tu configures le montage du volume par fstab et que tu n'ajoutes pas une option permettant le montage/démontage par les utilisateurs.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 05/04/2015, à 13:43

[résolu] Monter 1 partition simultanèment dans divers dossiers ?

#2 Le 05/04/2015, à 13:56

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#3 Le 05/04/2015, à 14:02

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#4 Le 05/04/2015, à 17:55

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#5 Le 05/04/2015, à 18:54

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#6 Le 06/04/2015, à 01:38

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#7 Le 06/04/2015, à 07:06

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#8 Le 06/04/2015, à 09:15

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#9 Le 06/04/2015, à 11:30

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#10 Le 06/04/2015, à 12:13

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#11 Le 07/04/2015, à 03:26

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#12 Le 07/04/2015, à 08:25

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#13 Le 08/04/2015, à 17:06

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

#14 Le 11/04/2015, à 05:30

Re : [résolu] Monter 1 partition simultanèment dans divers dossiers ?

Pied de page des forums