Partage de données

Page enfant de Storage and file management

Il arrive fréquemment de devoir partager ses données avec un collègue ou avec un autre groupe de recherche. Les grappes de Calcul Canada 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 projet 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 leur 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 des grappes de Calcul Canada 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 bénéficier de 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 777 name_of_file

accorde à tous les utilisateurs de la grappe 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 projet 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.

Définition de l'ID du groupe (SGID)

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 projet de Cedar et Graham par exemple, puisque les quotas de stockage sont comptabilisés par groupe.

Avec la permission SGID (Set Group ID) donnée à 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. Nous donnons la permission SGID au 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 ayant la permission SGID, ce nouveau répertoire sera associé au même groupe que le répertoire parent et possédera aussi la permission SGID.

[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 le SGID est toujours en place. 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

Permissions par défaut des systèmes de fichiers

Default filesystem permissions are defined by something called the umask. There is a default value that is defined on any Linux system. To display the current value in your session, you can run the command

[name@server ~]$ umask -S

For example, on Graham, you would get

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

This means that, by default, new files that you create can be read, written and executed by yourself, they can be read and executed by members of the group of the file, and they cannot be accessed by other people. The umask only applies to new files. Changing the umask does not change the access permissions of existing files.

There may be reasons to define default permissions more permissive (for example, to allow other people to read and execute files), or more restrictive (not allowing your group to read or execute files). Setting your own umask can be done either in a session, or in your .bashrc file, by calling the command

[name@server ~]$ umask <value>

where the <value> can take a number of octal values. Below is a table of useful options, depending on your use case :

umask value	umask meaning	Human-readable explanation
077	u=rwx,g=,o=	Files are readable, writable and executable by the owner only
027	u=rwx,g=rx,o=	Files are readable and executable by the owner and the group, but writable only by the owner
007	u=rwx,g=rwx,o=	Files are readable, writable and executable by the owner and the group
022	u=rwx,g=rx,o=rx	Files are readable and executable by everyone, but writable only by the owner
002	u=rwx,g=rwx,o=rx	Files are readable and executable by everyone, but writable only by the owner and the group

The umask is not the only thing that determines who can access a file.

• A user trying to access a file must have execute permission on all directories in the path to the file. For example, a file might have o=rx permissions but an arbitrary user could not read or execute it if the parent directory does not also have o=x permission.
• The user trying to access a file based on its group permissions must be a member of the file's group.
• You can explicitly change the permissions on a file or directory after it is created, using chmod.
• Access Control Lists (ACLs) also determine who can access a file.

Change of the default umask on Cedar, Béluga and Niagara

In the summer 2019, we discovered that the default umask was not the same on all Compute Canada servers. In the fall of 2019, we will be changing the default umask on these three servers to match the one from Graham. The default umask will change as follows:

Cluster	umask before the change	umask after the change
Béluga	002	027
Cedar	002	027
Niagara	022	027

This will mean that more restrictive permissions will be enforced on newly created files. If you need more permissive permissions for your workflow, you can change your default umask in your .bashrc. Our general advice is however to keep the default permissions.

Note that this change does not mean that your files have been inappropriately exposed in the past. Restrictive access permissions have been set on your home, project, and scratch directories since the beginning. Unless the permissions were changed to give execute permission on one of these folders to others, your files still cannot be accessed by other people.

Changing the permissions of existing files

If you want to change the permissions of existing files to match the new default permissions, you can use the chmod command as follow:

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

or, if you want to do it for a whole directory, you can run

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

Listes de contrôle d'accès

Sharing Access with an Individual

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, les systèmes nationaux de Calcul Canada offrent des listes de règles d'accès (ACLs 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.

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

[ someuser@server ]$ setfacl -m u:smithj:rx my_script.py

Partage d'un sous-répertoire

Pour accorder à un groupe particulier (ici wg-datasharing) la permission de lecture et écriture pour tout le contenu d'un répertoire particulier (/home/smithj/projects/def-smithj/shared_data), utilisez les commandes

[ someuser@server ]$ setfacl -d -m g:wg-datasharing:rwx /home/smithj/projects/def-smithj/shared_data
[ someuser@server ]$ setfacl -R -m g:wg-datasharing:rwx /home/smithj/projects/def-smithj/shared_data

La première commande configure les règles d'accès par défaut au répertoire /home/smithj/projects/def-smithj/shared_data pour que tous les fichiers et répertoires qui y sont créés héritent de la même règle ACL; elle est requise pour les nouvelles données. La deuxième commande configure les règles ACL au répertoire et à toutes les données comprises à ce moment dans /home/smithj/projects/def-smithj/shared_data; elle s'applique aux données existantes. Pour que cette méthode fonctionne, il faut s'assurer que

• le groupe particulier a été créé dans CCDB et que vous en êtes le propriétaire; vous pouvez ainsi ajouter ou supprimer des membres du groupe particulier;
• vous êtes aussi propriétaire du répertoire (ici, /home/smithj/projects/def-smithj/shared_data),
• puisque le groupe qui partagera les données n'est pas nécessairement le propriétaire du répertoire à partager, tous les répertoires parents sur son chemin doivent permettre un accès public avec la permission execute; la permission publique de lecture n'est pas nécessaire, à moins que vous ne l'accordiez.

$ 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

The first command sets default access rules to directory /home/<user>/projects/def-<PI>/shared_data, so any file or directory created within it will inherit the same ACL rule. It is required for new data. The second command sets ACL rules to directory /home/<user>/projects/def-<PI>/shared_data and all its content currently in it. So it is applicable only to existing data.

In order for this method to work the following things need to be in place:

• The directory, /home/smithj/projects/def-smithj/shared_data in our example, must be owned by you.
• Parent directories (and parents of parents, etc.) of the one you are trying to share must allow execute permission to the user you are trying to share with. This can be supplied with setfacl u:smithj:x ... in this example, or it can be supplied by allowing everyone entry, i.e. chmod o+x .... They do not need to have public read permission. In particular you will need to grant execute permission on the project directory (/projects/def-<PI>) either for everyone, or one-by-one to all the people you are trying to share your data with.

Partage de données avec un groupe

For more complicated data sharing scenarios (those involving multiple people on multiple clusters), it is also possible to create a data sharing group. A data sharing group is a special group to which all people with whom certain data is to be shared are added. This group is then given access permissions through ACLs.

You do not need a data sharing group except in specialized sharing circumstances.

Pour respecter ces exigences,
1. Faites parvenir un courriel à support@computecanada.ca pour demander la création du groupe qui partagera les données en spécifiant le nom du groupe et en mentionnant que vous souhaitez en être le propriétaire.
2. Lorsque la création du groupe est confirmée, connectez-vous à ccdb.computecanada.ca/services/ CCDB pour faire afficher la page des Services.

The steps below describe how to create a data sharing group. In this example it is called wg-datasharing

1. Send email to support@computecanada.ca requesting creation of data sharing group, indicate name of the group you would like to have and that you should be the owner.
2. When you receive confirmation from Compute Canada Support that the group has been created, go to ccdb.computecanada.ca/services/ and access it:

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).

5. Assurez-vous que /home/smithj/projects/def-smithj possède la permission execute.

[ someuser@server ]$ chmod  o+X /home/smithj/projects/def-smithj

Si vous n'avez pas les permissions requises pour exécuter cette commande, contactez le propriétaire du répertoire def-smithj (habituellement le chercheur principal) ou écrivez à support@calculcanada.ca.
6. Ajoutez le nouveau groupe à la liste de contrôle d'accès pour le répertoire.

[ someuser@server ]$ setfacl -d -m g:wg-datasharing:rwx /home/smithj/projects/def-smithj/shared_data
[ someuser@server ]$ setfacl -R -m g:wg-datasharing:rwx /home/smithj/projects/def-smithj/shared_data

Just as with individual user sharing, the parent directories of the data you are trying to share must have execute permissions either for everyone or for the data sharing group. In your project directory, this implies that your PI must give consent as follows (unless you have permission to do this yourself):

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

or

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

Finally, you can add your group to the ACL for the directory you are trying to share. The command parallel those needed to share with an individual:

$ 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