En ce qui concerne l'accès aux données de fichiers multi-protocoles, l'un des défis que Qumulo résout se concentre sur les flux de travail à protocoles mixtes. Gérer ces workflows, où les utilisateurs accèdent aux mêmes fichiers sur les deux NFS ainsi que SMB protocoles, est de savoir comment gérer le fichier autorisations.
Les utilisateurs POSIX accédant à leurs fichiers via NFS s'attendent à un ensemble d'autorisations différent de celui des utilisateurs Windows accédant à leurs fichiers via SMB. Afin de créer le flux de travail le plus fluide possible pour les clients dans des environnements multi-protocoles, Qumulo a automatisé Autorisations inter-protocoles (XPP) capacités permettant aux utilisateurs de travailler de manière transparente sur les plates-formes informatiques et les protocoles de mise en réseau. Cela permet aux utilisateurs sur les plates-formes Windows, Linux et macOS de collaborer en toute sécurité sans garanties d'autorisations ni schémas d'héritage élaborés.
XPP est un mode d'autorisation composé de nombreuses décisions prises par de nombreux ingénieurs au cours de plus d'un an. Il résout les incompatibilités inhérentes entre les autorisations POSIX et NT pour offrir aux utilisateurs de fichiers multi-protocoles une expérience d'autorisations aussi transparente que possible. Qu'est-ce qui a rendu ce problème si difficile à résoudre?
En tant qu'utilisateurs de systèmes de fichiers, nous avons tendance à ne pas trop penser aux autorisations - nous nous attendons à ce qu'elles fonctionnent. Cependant, disposer d'autorisations «justes» nécessite beaucoup de réflexion du point de vue de l'ingénierie lorsque vous avez deux protocoles complètement différents avec des attentes différentes travaillant dans le même environnement.
Autorisations POSIX vs NT
D'abord un petit historique. Les autorisations NT sont beaucoup plus fines que les autorisations POSIX. Les autorisations POSIX sont représentées par des bits de mode. Vous les avez déjà vus si vous avez déjà exécuté stat ou ls -l sur la ligne de commande. Les bits du mode POSIX peuvent exprimer les droits de lecture, d'écriture et d'exécution de fichiers/répertoires pour le propriétaire du fichier, le propriétaire du groupe et tout le monde.
| Lire | Écrire | Exécution | |
| Fichiers | Lire le fichier | Ajouter, modifier | Exécuter le fichier |
| Partages de fichiers | Répertoire de liste | Créer / renommer / supprimer des enfants | Répertoire de traversée (regardez les enfants) |
Dans le monde POSIX, il existe trois autorisations de base, ce qui signifie différentes choses lorsqu'elles sont appliquées à des fichiers par rapport à des répertoires.
Par ailleurs, les autorisations NT sont représentées par Listes de contrôle d'accès (ACL). Une liste de contrôle d’accès consiste en un ou plusieurs Entrées de contrôle d'accès (ACE), chacun d’eux contenant un dépositaire, l’utilisateur / groupe auquel il s’applique et un ensemble de droits que le dépositaire est autorisé ou refusé.
Ainsi, par exemple, une ACE peut exprimer quelque chose du type DENY bob read.
Quelques points importants sur les ACL:
- Les ACL sont évaluées dans l'ordre. Le premier ACE d'une liste de contrôle d'accès à s'appliquer à un fiduciaire l'emporte sur les éventuels ACE ultérieurs pouvant s'appliquer à ce fiduciaire.
- Les droits possibles dans Windows sont plus détaillés que simplement lire, écrire et exécuter - au total, il existe des droits possibles 14, y compris un droit de «contrôle total» qui équivaut aux autres droits combinés de 13.
- Les ACL s’appliquent par fichier / répertoire et les entrées peuvent être transmises des répertoires parents à leurs enfants. Nous appelons les entrées de contrôle d'accès qui ont été transmises à partir des répertoires parents «héritées» et les entrées de contrôle appliquées directement au fichier en question sont «explicites». Les entrées de contrôle ont des indicateurs qui indiquent comment et si elles sont héritées.
- Windows applique le concept d'une liste de contrôle d'accès canonique qui dicte l'ordre dans lequel les entrées de contrôle d'accès explicites et héritées doivent apparaître dans une liste de contrôle d'accès. Une ACL ordonnée canoniquement ressemble à ceci:
DENY explicites
AUTORISATIONS Explicites
DENYs hérités
PERMIS hérités
Cette capture d'écran ci-dessus montre les autorisations possibles dans Windows.
Plateforme de données de fichiers Qumulo et autorisations interprotocoles
Compte tenu des différences considérables entre les bits de mode POSIX et les ACL NT, comment Qumulo gère-t-il les autorisations? Nous avons notre propre version de la liste de contrôle d'accès, appelée la liste QACL. Il mappe presque 1: 1 vers la liste de contrôle d'accès NT, et stocke et comprend un sur-ensemble des droits pouvant être exprimés dans POSIX et Windows.
Les incohérences entre les modèles d'autorisations NT et POSIX peuvent se résumer à quatre opérations: affichage des bits de mode, modification des autorisations, création de fichiers et modification du propriétaire d'un fichier. Dans cet article, nous examinerons spécifiquement l'affichage des bits de mode et la modification des autorisations pour comprendre comment XPP résout ces incohérences.
Avant d'aller plus en détail sur les opérations d'autorisations spécifiques, il est important de noter que l'un des défis sous-jacents que XPP aborde est de savoir comment déterminer le ou les utilisateurs auxquels s'applique un ensemble d'autorisations. Ceci est vrai quel que soit le protocole: un système de fichiers distribué hautement disponible comme Plateforme de données de fichiers de Qumulo, là où il existe potentiellement plusieurs sources d'identité (par exemple, LDAP, Active Directory, les utilisateurs / groupes locaux de Qumulo), il peut être difficile de dire qui est qui en raison de la manière dont les utilisateurs sont stockés et identifiés en interne.
Avec XPP, Qumulo a introduit l'équivalence d'ID, qui utilise POSIX UID / GID comme identifiant commun à toutes les sources d'identité: Active Directory avec des extensions POSIX ou des mappages définis par l'utilisateur, OpenLDAP et les utilisateurs / groupes locaux de Qumulo. Cela permet de comparer ces valeurs pour déterminer qui est quelqu'un et de quel groupe il appartient.
Affichage du mode POSIX
Maintenant, rappelez-vous que Qumulo stocke les permissions sous la forme de QACL. Cela signifie que nous ne stockons pas le mode POSIX en tant que valeur sur le disque. Lorsque les utilisateurs accédant à Qumulo via NFS veulent voir les bits de mode pour un certain fichier, nous les générons à partir d'une QACL. C'est simple lorsque la QACL ne spécifie que des fiduciaires qui s'alignent exactement avec l'utilisateur / groupe / tout le monde POSIX, mais quand il y a d'autres fiduciaires «supplémentaires», cela devient plus compliqué.
Autoriser la lecture du propriétaire du fichier
Autoriser la lecture du propriétaire du groupe de fichiers
Autoriser tout le monde à lire
Dans cette simple ACL, il est facile de savoir quel mode POSIX afficher. Le propriétaire, le propriétaire du groupe et Tout le monde ont tous des droits de lecture, ce qui se traduit par 444. Mais que se passe-t-il si notre ACL ressemblait à ceci?
Autoriser la lecture du propriétaire du fichier
Autoriser la lecture du propriétaire du groupe de fichiers
Autoriser tout le monde à lire
AUTORISER alice lire, exécuter, écrire un fichier
Comment traitons-nous le «extra» ACE qui pointe vers alice? Pour afficher le mode POSIX le plus précis possible, nous devons savoir si Alice est le propriétaire du fichier et / ou appartient au groupe de fichiers. La découverte de ces deux informations est possible, mais coûteuse, et entraînerait de lourdes pertes de performances pour l'opération assez courante d'affichage du mode POSIX.
En particulier, pour savoir si alice fait partie du groupe du fichier, nous devons procéder à une expansion récursive de l'appartenance à un groupe à la fois pour le groupe du fichier et pour alice, en plus d'interroger toutes les sources d'identité pour déterminer si alice est propriétaire du fichier.
Ce que notre équipe d'ingénieurs a décidé de faire à la place, c'est de faire un compromis: Qumulo effectue des vérifications d'équivalence d'ID, la moins coûteuse des deux opérations, pour voir si un ACE «supplémentaire» est réellement extra, ou si c'est le propriétaire du fichier, mais autrement ajoute les autorisations de l'ayant droit supplémentaire au bit Tout le monde. Donc, en supposant qu'Alice n'est pas le propriétaire du fichier dans l'ACL ci-dessus, lors de l'état du fichier, un utilisateur verrait le bit de mode 447, avec les droits d'Alice repliés dans le bit Tout le monde.
Cela peut sembler inhabituel au début - il n’est pas vrai que tout le monde a les autorisations de lecture, d’écriture et d’exécution sur le fichier. Imaginez, cependant, que nous ayons plutôt indiqué 444 comme mode pour ce fichier. Quelqu'un qui examine ce mode peut supposer que personne ne dispose d'autorisations d'écriture ou d'exécution. Mais alice dispose de ces autorisations et laisse croire à l'utilisateur que le contraire présente un risque pour la sécurité. En affichant le mode le plus permissif possible pour une liste QACL donnée, Qumulo permet aux utilisateurs qui consultent des autorisations via NFS de savoir que les autorisations indiquées dans le bit Tout le monde appartiennent à quelqu'un.
Changer le mode POSIX
Un autre problème rencontré par l’équipe lorsqu’il s’est agi de faire en sorte que les autorisations NT et POSIX fonctionnent ensemble était de savoir comment gérer un chmod venant de NFS. N'oubliez pas que les QACL ont potentiellement des droits au-delà de POSIX en lecture / écriture / exécution, ainsi que des mandataires supplémentaires et des schémas d'héritage compliqués.
REFUSER alice lire, prendre possession (hériter de l'objet)
DENY charlie exécuter / traverser
Autoriser charlie lire, écrire un fichier
Autoriser la lecture du groupe de Charlie
Autoriser tout le monde à lire le contenu
AUTORISER bob lire, écrire (hériter uniquement)
Pour le fichier auquel cette QACL s'applique, charlie est le propriétaire. L'objet hériter du drapeau sur l'ACE d'alice signifie qu'il devrait être transmis à tous les fichiers / répertoires enfants, et le drapeau hérité uniquement sur le nom de bob signifie qu'il devrait être transmis et qu'il ne devrait pas affecter les autorisations de bob sur le fichier actuel. Comment pouvons-nous changer cette QACL quand quelqu'un fait chmod 555 dessus?
Avec XPP, l'équipe a développé un algorithme qui examine à la fois le mode demandé et la QACL préexistante, et manipule la QACL pour respecter l'intention du chmod tout en préservant la structure d'héritage de la QACL préexistante. Par exemple, la liste QACL obtenue après l'application du mode 555 à celui ci-dessus serait:
REFUSER Alice de prendre possession
REFUSER alice lire, prendre possession (hériter d'objet, hériter uniquement)
Autoriser charlie lire, exécuter / traverser
AUTORISER le groupe de Charlie à lire, exécuter / traverser
Autoriser tout le monde à lire, exécuter / parcourir
AUTORISER bob lire, écrire (hériter uniquement)
Que s'est-il passé ici? Les droits ont été modifiés pour refléter le mode demandé, 555. Notez également qu'il y avait une entrée DENY sur le propriétaire du fichier dans la QACL précédente qui n'existe plus car elle contredit le chmod.
Examinons maintenant les autres ACE. Pourquoi existe-t-il maintenant deux entrées de contrôle d'accès pour Alice?
REFUSER alice lire, prendre possession (hériter de l'objet)
Avant après
REFUSER Alice de prendre possession
REFUSER alice lire, prendre possession (hériter d'objet, hériter uniquement)
La première ACE conserve l’autorisation refusée sur un droit non-POSIX de l’entrée ACE originale (l’appropriation est un concept réservé aux PME), et la seconde n’est qu’une copie du premier, marqué en tant qu’héritage, de sorte qu’il puisse être utilisé. transmis sur les fichiers et les répertoires des enfants sans affecter le fichier actuel. Parce que l'ACE de bob n'a été hérité que pour commencer, cela n'affecte en aucun cas les autorisations de ce fichier et reste identique après le chmod.
The Bottom Line: Simplifier l'accès aux données de fichiers multiprotocole pour les utilisateurs
Les autorisations interprotocoles sont un mode d'autorisation, mais ce que cela signifie vraiment, c'est qu'il s'agit d'un ensemble de nombreuses décisions que l'équipe de Qumulo a prises pour tenter de répondre au mieux aux besoins des utilisateurs de Qumulo.
Il n'y a pas de réponse parfaite à ce problème. Cependant, en utilisant ID Equivalence, en choisissant de ne pas masquer l'accès existant dans les bits de mode et en affectant sélectivement les QACL lors du changement de mode POSIX et lors de la création, les autorisations interprotocoles offrent à nos utilisateurs une option simple, ne nécessitant aucune configuration et travaux.
En savoir plus
- Comprendre comment nos services de données simplifiez la gestion de quantités massives de données de fichiers.
- Lire la présentation technique et découvrez la plate-forme de données de fichiers haute performance de Qumulo.
Nous contacter
- Faites un essai routier. Démo Qumulo dans nos nouveaux laboratoires interactifs interactifs, ou demandez une démo ou un essai gratuit.
- Abonnez-vous au blog Qumulo pour les témoignages clients, les informations techniques, les tendances du secteur et les actualités sur les produits
