Introduction
L’analyste du commerçant doit pouvoir lire un jeu de données de produits, sans pouvoir le modifier. Le fichier est présent et ses blocs sont sains, mais un autre utilisateur peut tout de même recevoir Permission denied. L’état du stockage et l’autorisation répondent à des questions différentes : les données sont-elles disponibles, et cette identité a-t-elle le droit d’y accéder ?
HDFS utilise un propriétaire, un groupe et des bits de permission pour décider des accès de base. Vous travaillerez comme propriétaire ordinaire, labex, et partagerez un jeu de données avec l’identité analyst préparée via le groupe bigdata. Une autre identité ordinaire, nobody, représentera une personne extérieure à ce groupe. Le NameNode s’exécute sous l’identité hdfs ; vous n’êtes pas le superutilisateur HDFS.
Vous lirez les permissions existantes, établirez un accès de groupe en lecture seule et reproduirez un problème de traversée de répertoire. Ces vérifications portent sur les permissions HDFS, et non sur celles des fichiers Linux locaux. L’environnement est une configuration pédagogique à authentification simple, pas une démonstration d’authentification de production sécurisée comme Kerberos. Toutes les données d’exercice sont indépendantes des labs précédents. Utilisez le Terminal.
Lire les règles d’accès
Dans cette étape, vous identifierez le propriétaire, le groupe et les modes d’accès d’un jeu de données privé.
Commencez dans le répertoire local du projet :
cd /home/labex/project
L’option HDFS -ls -d liste l’entrée du répertoire lui-même plutôt que son contenu. Examinez ensemble le répertoire et le fichier :
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt
Les champs importants doivent inclure ces modes et ces identités ; les tailles et les horodatages varient :
drwx------ ... labex labex ... /user/labex/basic-permissions/team
-rw------- ... labex labex ... /user/labex/basic-permissions/team/products.txt
Le premier caractère décrit l’objet (d pour un répertoire, - pour un fichier). Les neuf caractères suivants forment trois groupes de trois : propriétaire, groupe et autres utilisateurs. r signifie lecture, w écriture et x exécution ou, pour les répertoires, traversée. Un tiret signifie que la permission correspondante est absente.
Pour un fichier, la lecture permet de lire son contenu et l’écriture de le modifier. Pour un répertoire, la lecture permet de lister les noms, l’écriture contrôle la création ou la suppression d’entrées conjointement avec la traversée, et l’exécution permet de passer par le répertoire pour accéder à un enfant nommé. Lire un fichier nécessite donc des permissions le long du chemin, ainsi que sur le fichier lui-même.
Le mode actuel du répertoire donne à labex un accès complet et aucun accès aux autres. Le fichier donne à labex un accès en lecture et en écriture. Confirmez que le propriétaire peut le lire :
hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Texte attendu :
notebook pen
folder notebook
Enregistrez la liste initiale avec une redirection de sortie locale :
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/initial-permissions.txt
Vous avez identifié un fichier privé, plutôt qu’un fichier manquant ou endommagé. La tâche suivante consiste à accorder au groupe prévu uniquement les accès nécessaires.
Partager avec un groupe en lecture seule
Dans cette étape, vous accorderez au groupe bigdata la traversée du répertoire et la lecture du fichier, puis testerez l’accès de l’analyste.
Les utilisateurs préparés labex et analyst sont tous deux membres de bigdata. L’opération HDFS -chgrp change le groupe d’un objet. En tant que propriétaire et membre du nouveau groupe, vous pouvez le définir sans devenir superutilisateur HDFS :
hdfs dfs -chgrp bigdata /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt
Définissez les modes avec -chmod. Chaque chiffre résume un ensemble de permissions : r=4, w=2 et x=1. Additionnez les valeurs nécessaires pour le propriétaire, le groupe et les autres :
| Mode | Propriétaire | Groupe | Autres |
|---|---|---|---|
750 sur un répertoire |
lire, écrire, traverser | lire et traverser | aucun accès |
640 sur un fichier |
lire et écrire | lire | aucun accès |
Appliquez le mode du répertoire :
hdfs dfs -chmod 750 /user/labex/basic-permissions/team
Appliquez le mode du fichier :
hdfs dfs -chmod 640 /user/labex/basic-permissions/team/products.txt
Testez maintenant l’identité réelle de l’analyste. sudo -u analyst exécute uniquement cette commande sous l’utilisateur ordinaire préparé ; le chemin absolu du client HDFS sélectionne le même outil. Il s’agit de tester une autre identité, et non d’effectuer les opérations habituelles sur les fichiers en tant qu’administrateur :
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Les deux mêmes lignes de produits doivent apparaître. Le groupe peut traverser le répertoire et lire le fichier.
Testez aussi l’écriture. -appendToFile ajouterait le contenu d’un fichier local à un fichier HDFS si l’accès l’autorisait. Le fichier de test en lecture seule fourni dans /tmp contient un libellé supplémentaire qui ne doit pas intégrer le jeu de données de confiance. Il se trouve hors du répertoire personnel local privé pour que l’identité ordinaire de test puisse le lire ; cela isole la permission d’écriture HDFS testée. La commande suivante doit échouer.
sudo -u analyst /usr/local/bin/hdfs dfs -appendToFile /tmp/labex-hdfs-write-probe.txt /user/labex/basic-permissions/team/products.txt
Repérez Permission denied et une indication d’accès en écriture. Cet échec est le résultat souhaité : l’analyste peut lire, mais ne peut pas ajouter de contenu. Un code de sortie non nul est normal pour ce refus intentionnel ; passez à l’étape suivante. Autoriser tout le monde à écrire dans le fichier supprimerait cette protection.
Diagnostiquer un problème de traversée de répertoire
Dans cette étape, vous modifierez un bit de permission, observerez l’échec d’accès obtenu et rétablirez uniquement l’accès nécessaire.
Le fichier autorise actuellement la lecture au groupe. Prévoyez ce qui se passe si le répertoire permet aux membres du groupe de lister les noms, mais plus de traverser le répertoire. 740 conserve l’accès du propriétaire et la lecture du groupe tout en retirant le x du groupe :
hdfs dfs -chmod 740 /user/labex/basic-permissions/team
Lisez le même fichier avec la même identité d’analyste. La commande suivante doit échouer.
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Le message de refus d’accès doit indiquer l’absence de permission de traversée sur le répertoire. Ajouter davantage de permissions de lecture au fichier ne résout pas ce problème : le chemin doit d’abord être traversable. Rétablissez le bit x du groupe sur le répertoire en revenant au mode pratiqué :
hdfs dfs -chmod 750 /user/labex/basic-permissions/team
Confirmez que la lecture par l’analyste fonctionne à nouveau :
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Les deux lignes originales doivent réapparaître. Enfin, testez une identité ordinaire extérieure au groupe de partage. nobody sert uniquement d’identité sans lien avec le groupe dans ce lab. La commande suivante doit échouer.
sudo -u nobody /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Le refus confirme que le partage de groupe n’a pas rendu le jeu de données public. Enregistrez la liste finale :
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/final-permissions.txt
Lisez le résultat :
cat /home/labex/project/output/final-permissions.txt
Le répertoire doit afficher drwxr-x--- et le fichier -rw-r-----, avec le propriétaire labex et le groupe bigdata. Comparez leur signification aux modes privés initiaux. Vous avez accordé à un groupe précis l’accès minimal nécessaire, plutôt que de désactiver les vérifications de permissions ou d’utiliser 777.
Résumé
Vous avez lu les modes HDFS propriétaire/groupe/autres, attribué un groupe de partage et utilisé des modes différents pour un répertoire et un fichier. Des tests avec les identités réelles ont confirmé que l’analyste pouvait lire sans écrire, tandis qu’un utilisateur extérieur ne pouvait pas lire.
En retirant puis en rétablissant la traversée du répertoire, vous avez compris pourquoi un fichier lisible peut rester inaccessible par son chemin. Dans le prochain défi, vous localiserez et corrigerez de façon autonome un problème de partage semblable.
