Sharing data/fr: Difference between revisions

<languages/>

''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 et nos grappes offrent tous les moyens pour ce faire.

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 [[Globus/fr#Partage_de_fichiers_avec_Globus|point de chute commun]] dans Globus.

==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 <tt>cd</tt> 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 :   

* 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   

{{Command|ls -l name_of_object }}  

Pour modifier les permissions associées à un fichier ou à un répertoire, utilisez la commande <tt>chmod</tt> 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 (<tt>r</tt>) pour ''read'', écrire (<tt>w</tt>) pour ''write'' ou exécuter (<tt>x</tt>) pour ''execute''. Les catégories d'utilisateur sont <tt>u</tt> (''user'') pour le propriétaire, <tt>g</tt> pour le groupe et  <tt>o</tt> (''others'') pour tous les autres utilisateurs de la grappe. Ainsi, la commande  

{{Command|chmod g+r file.txt}}

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 <tt>a</tt> pour signifier tous (''all''); ainsi  

{{Command|chmod a+r file.txt}}

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 <tt>chmod</tt> avec la notation octale mentionnée plus haut; par exemple,  

{{Command|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 <tt>chgrp</tt>.

===Protection ''sticky bit''===

Comme c'est souvent le cas lorsqu'un professeur travaille avec plusieurs étudiants et collaborateurs, l'[[Project_layout |espace projet]] se trouve dans un répertoire partagé par plusieurs utilisateurs qui ont des permissions de lecture, d'écriture ou d'exécution&nbsp;: 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é [https://en.wikipedia.org/wiki/Sticky_bit 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.

{{Command|chmod +t <directory name>}}

ou en notation octale avec le mode 1000, ainsi

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

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 ===

Si le bit <tt>setGID</tt> 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 <code>someuser</code> appartient avec la commande <source lang="console">

[someuser@server]$ groups

drwxrS---  3 someuser  def-someuser      4096 Oct 13 19:39 dirTest

</source>

=== Bit pour l'ID de l'utilisateur ===

Le bit <tt>setUID</tt> '''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 [https://https://fr.wikipedia.org/wiki/Umask <code>umask</code>]. Une valeur par défaut est définie pour chaque système Linux. Pour faire afficher cette valeur dans votre session, lancez  

{{Command|umask -S}}

{{Command|prompt=[user@gra-login1]$|umask -S

|result=u=rwx,g=rx,o=}}

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 <code>umask</code> dans une session ou encore dans votre fichier <code>.bashrc</code> avec la commande

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 <code>umask</code> dans votre <code>.bashrc</code>. 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 ===

== 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 :  

* <tt>getfacl</tt> pour connaitre les permissions définies dans la liste,  

====Partage d'un seul fichier====

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

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

</source>

==== Partage d'un sous-répertoire ====

; 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 <code>/home/<user>/projects/def-<PI>/shared_data</code>; 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 <code>/home/<user>/projects/def-<PI>/shared_data</code> et tout le contenu actuel. Elle ne s'applique qu'aux données '''existantes'''.

<div class="mw-translate-fuzzy">

</source>

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