Introducción
El analista de la empresa minorista necesita leer un conjunto de datos de productos, pero no debería poder modificarlo. El archivo está presente y sus bloques están saludables, pero otro usuario puede recibir Permission denied. El estado del almacenamiento y la autorización responden a preguntas diferentes: ¿están disponibles los datos y puede esta identidad acceder a ellos?
HDFS utiliza un propietario, un grupo y bits de permisos para decidir el acceso básico. Trabajará como el propietario normal, labex, y compartirá un conjunto de datos con la identidad analyst preparada mediante el grupo bigdata. Otra identidad normal, nobody, representará a alguien ajeno a ese grupo. El NameNode se ejecuta como hdfs; usted no es el superusuario de HDFS.
Interpretará los permisos existentes, establecerá el acceso de solo lectura para el grupo y reproducirá un problema de recorrido de directorios. Estas comprobaciones utilizan permisos de HDFS, no permisos de archivos locales de Linux. El entorno es una configuración didáctica de autenticación simple, no una demostración de autenticación segura de producción como Kerberos. Todos los datos de ejemplo son independientes de los laboratorios anteriores. Utilice Terminal.
Interprete las reglas de acceso
En este paso, identificará el propietario, el grupo y los modos de acceso de un conjunto de datos privado.
Comience en el directorio local del proyecto:
cd /home/labex/project
La opción -ls -d de HDFS lista la entrada del propio directorio en lugar de su contenido. Examine el directorio y el archivo juntos:
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt
Los campos importantes deberían incluir estos modos e identidades; los tamaños y las marcas de tiempo varían:
drwx------ ... labex labex ... /user/labex/basic-permissions/team
-rw------- ... labex labex ... /user/labex/basic-permissions/team/products.txt
El primer carácter describe el objeto (d para un directorio, - para un archivo). Los nueve caracteres siguientes forman tres grupos de tres: propietario, grupo y otros usuarios. r significa lectura, w significa escritura y x significa ejecución o, en directorios, recorrido. Un guion indica que el permiso correspondiente está ausente.
Para un archivo, la lectura permite leer su contenido y la escritura permite modificarlo. Para un directorio, la lectura permite listar nombres, la escritura controla la creación o eliminación de entradas junto con el permiso de recorrido, y la ejecución permite atravesar el directorio para acceder a un elemento hijo por su nombre. Por tanto, leer un archivo requiere permisos a lo largo de la ruta además de permisos sobre el propio archivo.
El modo actual del directorio concede acceso completo a labex y a nadie más. El archivo concede lectura y escritura a labex. Confirme que el propietario puede leerlo:
hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Texto esperado:
notebook pen
folder notebook
Guarde el listado inicial mediante redirección de salida local:
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/initial-permissions.txt
Ha identificado un archivo privado, no uno inexistente o dañado. La siguiente tarea consiste en conceder al grupo previsto únicamente el acceso que necesita.
Comparta con un grupo de solo lectura
En este paso, concederá al grupo bigdata permiso para atravesar el directorio y leer el archivo, y después probará el acceso del analista.
Los usuarios labex y analyst preparados pertenecen al grupo bigdata. La operación -chgrp de HDFS cambia el grupo de un objeto. Como propietario y miembro del nuevo grupo, puede establecerlo sin convertirse en superusuario de HDFS:
hdfs dfs -chgrp bigdata /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt
Establezca los modos con -chmod. Cada dígito numérico resume un conjunto de permisos: r=4, w=2 y x=1. Sume los valores necesarios para el propietario, el grupo y los demás:
| Modo | Propietario | Grupo | Otros |
|---|---|---|---|
750 en un directorio |
leer, escribir, atravesar | leer y atravesar | sin acceso |
640 en un archivo |
leer y escribir | leer | sin acceso |
Aplique el modo del directorio:
hdfs dfs -chmod 750 /user/labex/basic-permissions/team
Aplique el modo del archivo:
hdfs dfs -chmod 640 /user/labex/basic-permissions/team/products.txt
Ahora pruebe la identidad real del analista. sudo -u analyst ejecuta solo este comando como el usuario normal preparado; la ruta absoluta del cliente de HDFS selecciona la misma herramienta. Esta es una prueba de otra identidad, no una instrucción para realizar el trabajo habitual con archivos como administrador:
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Deberían aparecer las mismas dos líneas de productos. El grupo puede atravesar el directorio y leer el archivo.
Pruebe también la escritura. -appendToFile añadiría el contenido de un archivo local a un archivo de HDFS si el acceso lo permitiera. El archivo de prueba de solo lectura proporcionado en /tmp contiene una etiqueta adicional que no debe formar parte del conjunto de datos de confianza. Está fuera del directorio personal local privado para que la identidad normal de prueba pueda leerlo; esto aísla el permiso de escritura de HDFS que se comprueba. Se espera que el siguiente comando falle.
sudo -u analyst /usr/local/bin/hdfs dfs -appendToFile /tmp/labex-hdfs-write-probe.txt /user/labex/basic-permissions/team/products.txt
Busque Permission denied y una indicación de acceso de escritura. Ese fallo es el resultado deseado: el analista puede leer, pero no añadir contenido. Un estado de salida distinto de cero es normal para esta denegación intencional; continúe con el siguiente paso. Permitir que todo el mundo escriba en el archivo eliminaría esta protección.
Diagnostique un problema de recorrido de directorios
En este paso, cambiará un bit de permiso, observará el fallo de acceso resultante y restaurará únicamente el acceso necesario.
El archivo permite actualmente la lectura al grupo. Prediga qué sucederá si el directorio permite a los miembros del grupo listar nombres, pero ya no atravesarlo. 740 mantiene el acceso del propietario y la lectura del grupo, pero retira x al grupo:
hdfs dfs -chmod 740 /user/labex/basic-permissions/team
Lea el mismo archivo como el mismo analista. Se espera que el siguiente comando falle.
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
El mensaje de acceso denegado debería señalar la falta de permiso para atravesar el directorio. Esto no se corrige añadiendo más permiso de lectura al archivo: primero debe poder recorrerse la ruta. Restaure el bit x de grupo del directorio volviendo al modo practicado:
hdfs dfs -chmod 750 /user/labex/basic-permissions/team
Confirme que la lectura del analista vuelve a funcionar:
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Deberían volver a aparecer las dos líneas originales. Por último, pruebe una identidad normal ajena al grupo con el que comparte los datos. nobody se utiliza únicamente como identidad ajena en este laboratorio. Se espera que el siguiente comando falle.
sudo -u nobody /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
La denegación confirma que compartir con el grupo no hizo público el conjunto de datos. Guarde el listado final:
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/final-permissions.txt
Lea el resultado:
cat /home/labex/project/output/final-permissions.txt
El directorio debería mostrar drwxr-x--- y el archivo -rw-r-----, con propietario labex y grupo bigdata. Compare sus significados con los modos privados iniciales. Concedió a un grupo concreto el acceso mínimo necesario, en lugar de desactivar las comprobaciones de permisos o utilizar 777.
Resumen
Interpretó los modos de propietario, grupo y otros de HDFS, asignó un grupo para compartir y utilizó modos diferentes para un directorio y un archivo. Las comprobaciones con identidades reales confirmaron que el analista podía leer, pero no escribir, mientras que un usuario ajeno no podía leer.
Al retirar y restaurar el permiso de recorrido del directorio, aprendió por qué un archivo con permiso de lectura puede seguir siendo inaccesible a través de su ruta. En el siguiente desafío, localizará y reparará un problema de acceso compartido similar de forma independiente.
