Cuando se trata de acceso a datos de archivos multiprotocolo, uno de los desafíos que resuelve Qumulo se centra en los flujos de trabajo de protocolos mixtos. Gestionar estos flujos de trabajo, donde los usuarios acceden a los mismos archivos en ambos NFS y PYME protocolos, es cómo manejar el archivo permisos.
Los usuarios de POSIX que acceden a sus archivos a través de NFS esperan un comportamiento de permisos diferente al de los usuarios de Windows que acceden a sus archivos a través de SMB. Con el fin de crear el flujo de trabajo más fluido posible para los clientes en entornos multiprotocolo, Qumulo automatizó Permisos entre protocolos (XPP) capacidades que permiten a los usuarios trabajar sin problemas en plataformas informáticas y protocolos de red. Esto permite a los usuarios de las plataformas Windows, Linux y macOS colaborar de forma segura sin elaboradas protecciones de permisos ni esquemas de herencia.
XPP es un modo de permisos que consta de muchas decisiones tomadas por muchos ingenieros en el transcurso de más de un año. Aborda las incompatibilidades inherentes entre los permisos POSIX y NT para proporcionar a los usuarios de archivos multiprotocolo una experiencia de permisos lo más fluida posible. ¿Qué hizo que este problema fuera tan difícil de resolver?
Como usuarios de sistemas de archivos, tendemos a no pensar demasiado en los permisos; solo esperamos que funcionen. Pero tener permisos "solo funciona" requiere una gran cantidad de pensamiento desde una perspectiva de ingeniería cuando tiene dos protocolos completamente diferentes con distintas expectativas trabajando en el mismo entorno.
Permisos POSIX vs NT
Primero un poco de historia. Los permisos de NT son mucho más detallados que los permisos POSIX. Los permisos POSIX se representan mediante bits de modo. Los ha visto antes si alguna vez ha ejecutado stat o ls -l en la línea de comandos. Los bits del modo POSIX pueden expresar derechos de lectura, escritura y ejecución de archivos / directorios para el propietario del archivo, el propietario del grupo y todos los demás.
| Leer | Escribe. | Implementación | |
| archivos | Leer archivo | Añadir, Modificar | Ejecutar el archivo |
| Directorio | Directorio de la lista | Crear / renombrar / borrar niños | Directorio transversal (mira a los niños) |
En el mundo POSIX, hay tres permisos básicos, y significan cosas diferentes cuando se aplican a archivos en lugar de directorios.
Por otro lado, los permisos NT están representados por Listas de control de acceso (ACL). Un ACL consiste en uno o más Entradas de control de acceso (ACE), cada uno de los cuales contiene un fiduciario, el usuario / grupo al que se aplica y un conjunto de derechos que el fiduciario está autorizado o denegado.
Así, por ejemplo, una ACE podría expresar algo como las líneas de lectura de DENY bob read.
Algunos puntos importantes sobre los ACLs:
- Las ACL se evalúan en orden. La primera ACE en una ACL que se aplica a un fideicomisario gana sobre cualquier ACE posterior que pueda aplicarse a ese fideicomisario.
- Los derechos posibles en Windows son más detallados que solo leer, escribir y ejecutar; en total, hay derechos posibles de 14, incluido un derecho de “control total” que equivale a los otros derechos combinados de 13.
- Las ACL se aplican por archivo / directorio, y las entradas se pueden pasar de los directorios principales a sus secundarios. Las ACE que se transmitieron de los directorios principales "heredadas" y las ACE que de otra manera se aplicaron directamente a un archivo en cuestión son "explícitas". Las ACE tienen indicadores que indican cómo y si se heredan.
- Windows aplica el concepto de una ACL canónica que dicta el orden en que deben aparecer las ACE explícitas y heredadas en una ACL. Una ACL ordenada canónicamente se ve así:
DENYs explícitos
PERMITIDO explícito
DENYs heredados
PERMITIDOS Heredados
Esta captura de pantalla anterior muestra los posibles permisos en Windows.
Plataforma de datos de archivos Qumulo y permisos de protocolo cruzado
Dadas las diferencias bastante drásticas entre los bits de modo POSIX y las ACL de NT, ¿cómo maneja Qumulo los permisos? Tenemos nuestra propia versión de la ACL, llamada QACL. Asigna casi 1: 1 a NT ACL, y almacena y comprende un superconjunto de los derechos que se pueden expresar en POSIX y Windows.
Las inconsistencias entre los modelos de permisos NT y POSIX se pueden reducir a cuatro operaciones: mostrar bits de modo, cambiar permisos, crear archivos y cambiar el propietario de un archivo. En esta publicación, veremos específicamente la visualización de bits de modo y el cambio de permisos para comprender cómo XPP resuelve estas inconsistencias.
Antes de profundizar en las operaciones de permisos específicos, es importante tener en cuenta que uno de los desafíos subyacentes que aborda XPP es cómo determinar el usuario o usuarios a los que se aplica un conjunto de permisos. Esto es cierto independientemente del protocolo: sistema de archivos distribuido de alta disponibilidad como Plataforma de datos de archivos de Qumulo, donde hay potencialmente múltiples fuentes de identidad (por ejemplo, LDAP, Active Directory, usuarios / grupos locales de Qumulo), puede ser difícil saber quién es quién debido a la forma en que los usuarios se almacenan e identifican internamente.
Con XPP, Qumulo introdujo la equivalencia de ID, que utiliza POSIX UID / GID como un identificador común en todas las fuentes de identidad: Active Directory con extensiones POSIX o asignaciones definidas por el usuario, OpenLDAP y usuarios / grupos locales de Qumulo. Esto hace posible comparar estos valores para averiguar quién es alguien y a qué grupos pertenece.
Viendo el modo POSIX
Ahora, recuerde que Qumulo almacena permisos en forma de QACL. Esto significa que no almacenamos el modo POSIX como un valor en el disco. Cuando los usuarios que acceden a Qumulo a través de NFS quieren ver los bits de modo para un determinado archivo, los generamos a partir de una QACL. Esto es sencillo cuando la QACL solo especifica fideicomisarios que se alinean exactamente con el usuario / grupo / todos de POSIX, pero cuando hay otros fideicomisarios "adicionales", se vuelve más complicado.
PERMITIR la lectura del propietario del archivo
PERMITIR la lectura del propietario del grupo de archivos
PERMITIR que todos lean
En esta simple ACL, es fácil saber qué modo POSIX mostrar. El propietario, el propietario del grupo y Todos tienen derechos de lectura, lo que se traduce en 444. Pero, ¿y si nuestro ACL se veía así?
PERMITIR la lectura del propietario del archivo
PERMITIR la lectura del propietario del grupo de archivos
PERMITIR que todos lean
PERMITIR a Alice leer, ejecutar, escribir archivos
¿Cómo manejamos el ACE "extra" que apunta a Alice? Para poder mostrar el modo POSIX más preciso posible, necesitamos saber si alice es el propietario del archivo y / o pertenece al grupo del archivo. Descubrir estas dos piezas de información es posible, pero costoso, y causaría un gran impacto en el rendimiento de la operación bastante común de mostrar el modo POSIX.
En particular, para averiguar si Alice está en el grupo del archivo, deberíamos realizar una expansión recursiva de la membresía del grupo tanto para el grupo del archivo como para alice, además de consultar todas las fuentes de identidad para descubrir si alice es el propietario del archivo.
Lo que nuestro equipo de ingeniería decidió hacer en su lugar es hacer una compensación: Qumulo realiza verificaciones de equivalencia de ID, la menos costosa de las dos operaciones, para ver si un ACE "adicional" es realmente adicional, o si es el propietario del archivo, pero de lo contrario agrega los permisos del fideicomisario adicional al bit Everyone. Entonces, asumiendo que Alice no es la propietaria del archivo en la ACL anterior, al establecer el archivo, un usuario vería el bit de modo 447, con los derechos de Alice plegados en el bit Everyone.
Esto puede parecer inusual al principio; en realidad no es cierto que todos hayan leído, escrito y ejecutado los permisos para el archivo. Imagina, sin embargo, que en cambio mostramos 444 como el modo para este archivo. Alguien que mira ese modo podría asumir que nadie tenía permisos de escritura o ejecución. Pero Alicia sí tiene esos permisos, y llevar al usuario a creer que, de lo contrario, introduce un riesgo de seguridad. Al mostrar el modo más permisivo posible para una QACL dada, Qumulo les permite a los usuarios ver los permisos sobre NFS saber que alguien, si no todos, tiene los permisos indicados en el bit Todos.
Cambiando el modo POSIX
Otro problema que el equipo encontró al abordar el problema de hacer que los permisos de NT y POSIX trabajen juntos fue cómo manejar un chmod que viene sobre NFS. Recuerde, las QACL tienen potencialmente derechos más allá de POSIX de lectura / escritura / ejecución, así como administradores adicionales y esquemas de herencia complicados.
NEGAR que Alice lea, tome posesión (Objeto heredado)
DENY charlie ejecutar / atravesar
PERMITA que charlie lea, escriba el archivo
PERMITA que el grupo de charlie lea
PERMITIR que todos lean el contenido
PERMITIR a bob leer, escribir (solo heredar)
Para el archivo al que se aplica esta QACL, charlie es el propietario. El indicador de herencia del objeto en el ACE de alice significa que debe transmitirse a cualquier archivo / directorio secundario, y el indicador de solo herencia en el de bob significa que debe transmitirse y que no debe afectar los permisos de bob en el archivo actual. ¿Cómo cambiamos este QACL cuando alguien hace chmod 555 en él?
Con XPP, el equipo desarrolló un algoritmo que analiza tanto el modo solicitado como la QACL preexistente, y manipula la QACL para cumplir con la intención del chmod, al tiempo que conserva la estructura de herencia de la QACL preexistente. Como ejemplo, la QACL resultante después de aplicar el modo 555 al anterior sería:
NEGAR que Alice tome posesión
NEGAR que Alice lea, tome posesión (Objeto heredado, solo heredado)
PERMITIR a charlie leer, ejecutar / atravesar
PERMITA que el grupo de charlie lea, ejecute / recorra
PERMITIR que todos lean, ejecuten / recorran
PERMITIR a bob leer, escribir (solo heredar)
¿Lo que pasó aquí? Los derechos se han cambiado para reflejar el modo solicitado, 555. Observe también que hubo una entrada DENY en el propietario del archivo en la QACL anterior que ya no existe porque contradice el chmod.
Ahora veamos las otras ACE. ¿Por qué ahora hay dos ACE para Alicia?
NEGAR que Alice lea, tome posesión (Objeto heredado)
Antes después
NEGAR que Alice tome posesión
NEGAR que Alice lea, tome posesión (Objeto heredado, solo heredado)
El primer ACE conserva el permiso denegado en un derecho que no es POSIX en el ACE original (tomar posesión es un concepto solo de SMB), y el segundo es solo una copia del primero, marcado como solo heredado para que pueda ser pasado a los archivos y directorios de los niños sin afectar el archivo actual. Como ACE de bob se heredó, solo para empezar, no afecta los permisos en este archivo de todos modos, y sigue siendo el mismo después del chmod.
Conclusión: simplificación del acceso a datos de archivos multiprotocolo para los usuarios
Permisos de protocolo cruzado es un modo de permisos, pero lo que eso realmente significa es que es una colección de muchas decisiones que el equipo de Qumulo tomó en un intento por adaptarse mejor a las necesidades de los usuarios de Qumulo.
No hay una respuesta perfecta cuando se trata de este problema. Sin embargo, al usar Equivalencia de ID, elegir no ocultar el acceso existente en los bits de modo y afectar selectivamente las QACL al cambiar el modo POSIX y al crear, los Permisos de protocolo cruzado brindan una opción a nuestros usuarios que es simple, no requiere configuración y solo obras.
Más información
- Comprenda cómo nuestros servicios de datos simplifica la gestión de grandes cantidades de datos de archivos.
- Leer la descripción técnica y conozca la plataforma de datos de archivos de alto rendimiento de Qumulo.
Contáctanos
- Haz una prueba de manejo. Haga una demostración de Qumulo en nuestros nuevos laboratorios prácticos interactivos, o solicite una demostración o una prueba gratuita.
- Suscríbete al blog de Qumulo para historias de clientes, conocimientos técnicos, tendencias de la industria y noticias de productos.
