Sharing data/fr

Page enfant de Storage and file management

ATTENTION : N'utilisez jamais la commande chmod -R 777 dans vos répertoires et surtout pas dans votre répertoire /home. Ce serait un ÉNORME risque à la sécurité de vos données et c'est inacceptable sur des systèmes partagés tels que nos grappes de calcul. En plus, cette commande n'est jamais vraiment nécessaire.

Il arrive fréquemment de devoir partager ses données avec un collègue ou avec un autre groupe de recherche et nos grappes offrent tous les moyens pour ce faire.

Pour partager des données avec un membre d'un groupe de recherche dont vous faites partie, la meilleure approche est d'utiliser l'espace /project disponible aux membres du groupe. Si vous devez créer un groupe qui utilisera une des grappes nationales, communiquez avec le soutien technique, car les utilisateurs ne peuvent créer leurs propres groupes.

Pour partager des données avec une personne qui ne détient pas de compte sur la grappe que vous utiliserez, vous pouvez créer un point de chute commun dans Globus.

Pour partager des données avec un autre utilisateur qui détient un compte sur la même grappe, mais qui ne fait pas partie du même groupe, le moyen le plus simple est de vous servir des permissions du système de fichiers en question, ce qui est ici le sujet principal.

La personne avec laquelle vous voulez partager vos données doit pouvoir accéder à tous les répertoires à partir des espaces /scratch ou /project, jusqu'au répertoire qui contient le fichier. Pour avoir accès, par exemple, à un document placé dans un coffre-fort situé dans une pièce de votre appartement, il ne suffit pas de me fournir la combinaison pour ouvrir le coffre-fort; je dois aussi pouvoir entrer dans l'édifice, puis dans votre appartement, puis dans la pièce où se trouve le coffre-fort. Dans le contexte d'un système de fichiers, ceci signifie accorder à l'autre utilisateur une permission d'exécution à tous les répertoires entre le répertoire racine (par exemple /scratch ou /project) et le répertoire qui contient le fichier en question.

Permissions des systèmes de fichiers

À l'instar de la plupart des systèmes de fichiers modernes, ceux de nos grappes possèdent des fonctionnalités permettant de lire, écrire et exécuter des fichiers et des répertoires. Quand un utilisateur essaie avec la commande cd de lire, modifier ou supprimer un fichier ou encore obtenir l'accès à un répertoire, le noyau Linux (le kernel) vérifie d'abord les permissions. Si l'action est impossible, un message annonce que la permission n’est pas accordée. Il existe trois catégories d'utilisateurs pour les objets fichiers ou répertoires d'un système de fichiers :

• le propriétaire de l'objet, habituellement l'utilisateur ayant créé cet objet
• les membres du groupe de l'objet, habituellement les mêmes que les membres du groupe par défaut du propriétaire
• tous les autres

À chacune de ces catégories d'utilisateurs peuvent être associées les permissions de lecture, d'écriture et d'exécution de l'objet. Avec trois catégories d'utilisateurs et trois types de permissions, il y a donc une possibilité de neuf permissions pouvant être associées à chaque objet.

Pour connaitre les permissions associées à un objet, utilisez

[name@server ~]$ ls -l name_of_object

Le résultat en sortie indique les permissions associées au propriétaire, au groupe et aux autres. Par exemple, ‑rw‑r‑‑r‑‑ permet au propriétaire seulement la lecture et l'écriture (read et write); la lecture est permise aux membres du groupe et à tous les autres utilisateurs. Le résultat montre aussi le nom du propriétaire de l'objet et le groupe.

Pour modifier les permissions associées à un fichier ou à un répertoire, utilisez la commande chmod suivie de la catégorie d'utilisateur puis du signe plus (+) ou moins (-) pour soit allouer ou retirer la permission, et enfin, la nature de la permission, soit lire (r) pour read, écrire (w) pour write ou exécuter (x) pour execute. Les catégories d'utilisateur sont u (user) pour le propriétaire, g pour le groupe et o (others) pour tous les autres utilisateurs de la grappe. Ainsi, la commande

[name@server ~]$ chmod g+r file.txt

accorde la permission de lecture à tous les membres du groupe auquel appartient le fichier file.txt, alors que la commande

[name@server ~]$ chmod o-x script.py

retire la permission d'exécuter le fichier script.py à tous, à l'exception du propriétaire et du groupe. On utilise la catégorie d'utilisateur a pour signifier tous (all); ainsi

[name@server ~]$ chmod a+r file.txt

indique que tous les utilisateurs de la grappe peuvent lire le fichier file.txt.

Pour ce qui est des permissions sous Unix, plusieurs utilisent la notation octale, même si cette dernière est moins intuitive. Les permissions pour une catégorie d'utilisateur sont représentées par trois bits qui sont interprétés comme un chiffre de 0 à 7 avec la formule (read_bit)*4 + (write_bit)*2 + (execute_bit)*1. Dans notre exemple, la représentation octale serait 4+2+0 = 6 pour le propriétaire et 4+0+0 = 4 pour le groupe et les autres, soit la valeur 644.

Notez que pour avoir vos permissions reliées à un fichier, vous devez avoir accès au répertoire qui contient ce fichier; vous devrez donc avoir les permissions en lecture et en exécution (5 et 7 en notation octale) pour ce répertoire.

Pour modifier les permissions, utilisez la commande chmod avec la notation octale mentionnée plus haut; par exemple,

[name@server ~]$ chmod 770 name_of_file

accorde à tous les utilisateurs de votre groupe les permissions d'écriture, de lecture et d'exécution. Bien entendu, vous pouvez seulement modifier les permissions associées à un fichier ou à un répertoire dont vous êtes propriétaire. Pour modifier le groupe, utilisez la commande chgrp.

Protection sticky bit

Comme c'est souvent le cas lorsqu'un professeur travaille avec plusieurs étudiants et collaborateurs, l'espace /project se trouve dans un répertoire partagé par plusieurs utilisateurs qui ont des permissions de lecture, d'écriture ou d'exécution : il faut donc s'assurer que les fichiers et les répertoires ne puissent être supprimés par un autre utilisateur que leur propriétaire. Le système de fichiers sous Unix comporte la fonctionnalité sticky bit qui empêche qu'un fichier soit supprimé ou renommé par un autre utilisateur que le propriétaire du fichier ou du répertoire. Sans ce sticky bit, les utilisateurs qui ont des permissions de lecture et d'écriture pour un répertoire peuvent renommer ou supprimer tous les fichiers du répertoire, même s'ils n'en sont pas les propriétaires. Pour positionner les permissions rwxrwxr-- et le stickly bit sur un répertoire, utilisez la commande chmod ainsi

[name@server ~]$ chmod +t <directory name>

ou en notation octale avec le mode 1000, ainsi

[name@server ~]$ chmod 1774 <directory name>

Dans ls -l, le sticky bit est représenté par la lettre t (ou T), à la fin du champ des permissions, comme suit

$ ls -ld directory
drwxrws--T 2 someuser def-someuser 4096 Sep 25 11:25 directory

Il est désactivé par la commande

[name@server ~]$ chmod -t <directory name>

ou en octal,

[name@server ~]$ chmod 0774 <directory name>

Pour l'espace projet, le propriétaire du répertoire est le chercheur principal qui parraine les étudiants et les collaborateurs.

Bit pour l'ID du groupe

Lorsque des fichiers et des répertoires sont créés dans un répertoire parent, il est très utile dans certains cas de pouvoir associer automatiquement le propriétaire ou le groupe de ces nouveaux fichiers et répertoires au répertoire parent ou au groupe auquel ils sont reliés. Ceci est très important au fonctionnement des fichiers de système des espaces /project de Cedar et Graham par exemple, puisque les quotas de stockage sont comptabilisés par groupe.

Si le bit setGID est activé pour un répertoire, les nouveaux fichiers et sous-répertoires créés sous celui-ci héritent du propriétaire du groupe auquel le répertoire est associé. Voyons un exemple.

Vérifiez d'abord quels sont les groupes auxquels someuser appartient avec la commande

[someuser@server]$ groups
someuser def-someuser

someuser appartient à deux groupes : someuser et def-someuser. Dans le répertoire actif, il y a un répertoire qui appartient au groupe def-someuser.

[someuser@server]$ ls -l
drwxrwx---  2 someuser   def-someuser       4096 Oct 13 19:39 testDir

Si nous créons un fichier dans ce répertoire, nous voyons qu'il appartient à someuser, groupe par défaut de someuser.

[someuser@server]$ touch dirTest/test01.txt
[someuser@server]$ ls -l dirTest/
-rw-rw-r-- 1 someuser   someuser    0 Oct 13 19:38 test01.txt

Nous ne voulons probablement pas nous trouver dans /project, mais nous voulons qu'un fichier nouvellement créé possède le même groupe que celui du répertoire parent. Activez la permission setGID du répertoire parent ainsi

[someuser@server]$ chmod g+s dirTest
[someuser@server]$ ls -l
drwxrws---  2 someuser   def-someuser       4096 Oct 13 19:39 dirTest

Remarquez que la permission x des permissions du groupe est maintenant s; les nouveaux fichiers créés dans dirTest seront associés au même groupe que le répertoire parent.

[someuser@server]$ touch dirTest/test02.txt
[someuser@server]$ ls -l dirTest
-rw-rw-r-- 1 someuser   someuser      0 Oct 13 19:38 test01.txt
-rw-rw-r-- 1 someuser   def-someuser  0 Oct 13 19:39 test02.txt

Si nous créons un répertoire sous un répertoire où setGID est activé, ce nouveau répertoire sera associé au même groupe que le répertoire parent et setGID sera aussi activé.

[someuser@server]$ mkdir dirTest/dirChild
[someuser@server]$ ls -l dirTest/
-rw-rw-r-- 1 someuser   someuser      0 Oct 13 19:38 test01.txt
-rw-rw-r-- 1 someuser   def-someuser  0 Oct 13 19:39 test02.txt
drwxrwsr-x 1 someuser   def-someuser  0 Oct 13 19:39 dirChild

Il peut être important de distinguer entre S (majuscule) et s. Le S majuscule indique que les permissions d'exécution ont été retirées du répertoire, mais que setGID est toujours activé. Il est facile de confondre les deux formes, ce qui peut créer des problèmes de permission inattendus, par exemple l'impossibilité pour les autres membres du groupe d'accéder à des fichiers de votre répertoire.

[someuser@server]$ chmod g-x dirTest/
[someuser@server]$ ls -l
drwxrS---  3 someuser   def-someuser       4096 Oct 13 19:39 dirTest

Bit pour l'ID de l'utilisateur

Le bit setUID ne fonctionne pas sur nos grappes. Il est désactivé pour des raisons de sécurité.

Permissions par défaut des systèmes de fichiers

Les permissions par défaut sont définies par l'attribut umask. Une valeur par défaut est définie pour chaque système Linux. Pour faire afficher cette valeur dans votre session, lancez

[name@server ~]$ umask -S

Par exemple, le résultat sur Graham serait

[user@gra-login1]$ umask -S
u=rwx,g=rx,o=

Ceci signifie que par défaut, les nouveaux fichiers que vous créez peuvent être lus, modifiés et exécutés par vous-même; ils peuvent être lus et exécutés par les membres du groupe du fichier; les autres utilisateurs n'y ont pas accès. L'attribut umask ne s'applique qu'aux nouveaux fichiers; le fait de changer umask ne change pas les permissions d'accès aux fichiers existants.

Vous pourriez vouloir définir des permissions moins restrictives (par exemple pour permettre à d'autres utilisateurs de lire et exécuter les fichiers) ou plus restrictives (par exemple pour empêcher votre groupe de lire ou exécuter les fichiers). Vous pouvez définir votre attribut umask dans une session ou encore dans votre fichier .bashrc avec la commande

[name@server ~]$ umask <value>

où <value> est une valeur octale. Le tableau suivant montre des options utiles de umask.

Valeur	Permissions	Effet
077	u=rwx,g=,o=	Les fichiers peuvent être lus, modifiés et exécutés par le propriétaire seulement.
027	u=rwx,g=rx,o=	Les fichiers peuvent être lus et exécutés par le propriétaire et par le groupe, mais peuvent être modifiés par le propriétaire seulement.
007	u=rwx,g=rwx,o=	Les fichiers peuvent être lus, modifiés et exécutés par le propriétaire et par le groupe.
022	u=rwx,g=rx,o=rx	Les fichiers peuvent être lus et exécutés par tous, mais peuvent être modifiés par le propriétaire seulement.
002	u=rwx,g=rwx,o=rx	Les fichiers peuvent être lus et exécutés par tous, mais peuvent être modifiés par le propriétaire et par le groupe.

D'autres conditions déterminent l'accès aux fichiers.

• L'utilisateur qui veut avoir accès à un fichier doit avoir la permission d'exécution pour tous les répertoires dans le chemin de ce fichier. Par exemple, un fichier pourrait avoir les permissions o=rx, mais un utilisateur régulier ne pourra le lire ni l'exécuter si le répertoire parent n'a pas aussi la permission o=x.
• L'utilisateur qui veut avoir accès à un fichier ayant des permissions de groupe doit être membre du groupe du fichier.
• Les permissions d'un fichier ou d'un répertoire peuvent être modifiées après leur création avec chmod.
• L'accès aux fichiers est aussi déterminé par les listes de contrôle d'accès (ACL pour Access Control List).

Modification de l'attribut par défaut umask sur Cedar, Béluga et Niagara

À l'été de 2019, nous avons remarqué que l'attribut umask n'était pas le même sur tous nos serveurs. En date du 16 octobre 2019, umask a été modifié et est maintenant le même que sur Graham.

Grappe	Valeur antérieure	Valeur depuis 2019-10-16
Béluga	002	027
Cedar	002	027
Niagara	022	027

Ceci signifie que les permissions sont devenues plus restrictives pour les fichiers nouvellement créés. Si ce n'est pas convenable, vous pouvez modifier votre umask dans votre .bashrc. En général, nous recommandons toutefois de conserver les permissions définies par défaut.

Vos fichiers n'étaient pas plus à risque avant cette modification. Depuis le début, les permissions d'accès sont restrictives pour vos répertoires /home, /project et /scratch; ils ne peuvent être accédés par les autres utilisateurs à moins que vous leur ayez accordé le droit d'exécuter.

Changer les permissions de fichiers existants

Pour que les permissions soient les mêmes que les nouvelles permissions par défaut, vous pouvez utiliser chmod comme suit :

[name@server ~]$ chmod g-w,o-rx <file>

Pour le répertoire au complet, utilisez

[name@server ~]$ chmod -R g-w,o-rx <directory>

Listes de contrôle d'accès

Partage de données avec un autre utilisateur

Les systèmes d'exploitation de type Unix fonctionnent avec ces permissions depuis plusieurs années, mais les possibilités sont limitées. Comme il n'y a que trois catégories d'utilisateurs (propriétaire, groupe, autres), comment permettre la lecture à un utilisateur en particulier qui n'appartient pas à un groupe? Faut-il alors permettre à tous de lire le fichier? Heureusement, la réponse est non, puisque dans de tels cas, nos systèmes nationaux offrent des listes de règles d'accès (ACL pour access control lists) par utilisateur. Les deux commandes pour ce faire sont :

• getfacl pour connaitre les permissions définies dans la liste,
• setfacl pour modifier ces permissions.

Partage d'un seul fichier

Par exemple, pour accorder à l'utilisateur smithj la permission de lire et exécuter le fichier my_script.py, la commande serait

$ setfacl -m u:smithj:rx my_script.py

Partage d'un sous-répertoire

Pour accorder un accès en lecture et écriture à un seul utilisateur dans un sous-répertoire, incluant les nouveaux fichiers qui y seront créés, utilisez les commandes suivantes :

$ setfacl -d -m u:smithj:rwX /home/<user>/projects/def-<PI>/shared_data
$ setfacl -R -m u:smithj:rwX /home/<user>/projects/def-<PI>/shared_data

Note

L'attribut X (majuscule) donne la permission execute seulement quand le répertoire ou le fichier possède déjà la permission d'exécution. Pour pouvoir être vu, un répertoire doit avoir la permission d'exécution.

La première commande détermine les règles d'accès au répertoire /home/<user>/projects/def-<PI>/shared_data; tous les fichiers et répertoires qui y seront créés hériteront de la même règle ACL. Elle est nécessaire pour les nouvelles données. La deuxième commande détermine les règles ACL pour le répertoire /home/<user>/projects/def-<PI>/shared_data et tout le contenu actuel. Elle ne s'applique qu'aux données existantes.

Pour que cette méthode fonctionne, il faut :

• que vous soyez propriétaire du répertoire, /home/smithj/projects/def-smithj/shared_data dans notre exemple;
• que les répertoires parents (et parents des parents, etc.) de celui que vous voulez partager accordent la permission d'exécuter à l'utilisateur avec qui vous voulez le partager. Dans notre exemple, vous pourriez utiliser setfacl -m u:smithj:X ... ou encore accorder la permission à tous les utilisateurs avec chmod o+x .... Il n'est pas nécessaire d'accorder une permission de lecture publique. En particulier, vous devrez accorder une permission d'exécuter pour le répertoire (/projects/def-<PI>) soit à tous les utilisateurs, soit à chaque utilisateur (un à la fois) avec qui vous voulez partager vos données.
• pour partager un répertoire du système de fichiers /project, donnez à vos collaborateurs un chemin qui commence par /project et non /home/<user>/projects. Ce dernier chemin contient des liens symboliques (simlinks ou raccourcis) vers les répertoires physiques de /project et le répertoire à trouver ne pourra pas être rejoint par d'autres qui n'auraient pas accès à votre répertoire /home. La commande realpath vous permet d'obtenir le chemin physique auquel pointe le simlink. Par exemple, realpath /home/smithj/projects/def-smithj/shared_data pourrait retourner /project/9041430/shared_data. Le chemin physique vers un répertoire /project n'est pas le même pour toutes nos grappes; si votre répertoire /project doit être partagé sur plus d'une grappe, vérifiez le chemin physique sur chacune avec realpath.

Supprimer les listes de contrôle d'accès

Pour supprimer récursivement tous les attributs dans un répertoire, utilisez

setfacl -bR /home/<user>/projects/def-<PI>/shared_data

Partage de données avec un groupe

Dans les cas de partage de données plus complexes (avec plusieurs utilisateurs sur plusieurs grappes), il est possible de créer un groupe de partage. Il s'agit d'un groupe spécial composé des utilisateurs avec lesquels les données doivent être partagées. Le groupe obtient ses permissions d'accès via des listes de contrôle d'accès (ACL).

Vous aurez besoin d'un groupe dans des cas particuliers de partage de données.

Création d'un groupe de partage de données

La procédure suivante décrit la création du groupe wg-datasharing.

1. Écrivez au soutien technique pour demander la création du groupe; indiquez le nom du groupe et dites que vous en êtes le propriétaire.
2. Quand vous recevez la confirmation de la création du groupe, allez à ccdb.computecanada.ca/services/.

3. Cliquez sur le nom du groupe en question pour faire afficher les détails de ce groupe.

4. Ajoutez un membre (par exemple, Victor Van Doom avec son identifiant CCI vdv-888).

Utilisation d'un groupe de partage de données

Comme pour le partage avec un seul utilisateur, les répertoires parents des données que vous voulez partager doivent avoir la permission d'exécuter, soit pour tous, soit pour le groupe avec lequel vous voulez les partager. Ceci signifie que dans le répertoire /project, le chercheur principal doit consentir comme suit (à moins que vous n'ayez la permission de faire ceci vous-même) :

$ chmod  o+X /project/def-<PI>/

ou

$ setfacl -m g:wg_datasharing:X /project/def-<PI>/

Enfin, vous pouvez ajouter votre groupe à la liste de contrôle d'accès (ACL) pour le répertoire que vous voulez partager. Les commandes sont les mêmes que celles pour le partage avec un utilisateur :

$ setfacl -d -m g:wg-datasharing:rwx /home/<user>/projects/def-<PI>/shared_data
$ setfacl -R -m g:wg-datasharing:rwx /home/<user>/projects/def-<PI>/shared_data

Globus is a file transfer service