Par Jacqueline Kong

L’un des défis que Qumulo essaie de résoudre concerne les workflows à protocole mixte où les utilisateurs accèdent aux mêmes fichiers via les deux NFS et SMB protocoles est comment gérer les autorisations de fichiers. Les utilisateurs POSIX accédant à leurs fichiers via NFS s'attendent à un ensemble de comportements d'autorisation différent de celui des utilisateurs Windows accédant à leurs fichiers via SMB. Ce printemps, afin de créer le flux de travail le plus fluide possible pour les clients dotés d'environnements à protocole mixte, Qumulo a introduit les autorisations entre protocoles.

Les autorisations entre protocoles (XPP) sont un mode d’autorisations comprenant de nombreuses décisions prises par de nombreux ingénieurs au cours d’une période de plus d’un an. Il corrige les incompatibilités inhérentes entre les autorisations POSIX et NT afin de fournir aux utilisateurs de protocoles mixtes une expérience des 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.

Renseignements généraux

Les autorisations NT sont beaucoup plus détaillées que les autorisations POSIX. Autorisations POSIX sont représentés par des bits de mode. Vous les avez déjà vues auparavant si vous avez déjà exécuté stat ou ls -l sur la ligne de commande. Les bits en mode POSIX peuvent exprimer des 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 tous les autres.

Lues Écrire Exécuter
Fichiers Lire le fichier Ajouter, modifier Exécuter le fichier
Répertoires 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

Les autorisations possibles dans Windows.

La solution de Qumulo

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 être résumées en 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 nous intéresserons plus particulièrement à l'affichage des bits de mode et à la modification des autorisations afin de comprendre comment les autorisations entre protocoles permettent de résoudre ces incohérences.

Avant d’approfondir certaines opérations relatives aux autorisations, il est important de noter que l’un des problèmes sous-jacents à l’administration d’autorisations de protocole croisées consiste à déterminer le ou les utilisateurs auxquels s’applique un ensemble d’autorisations. Cela est vrai quel que soit le protocole: dans un environnement tel que Qumulo, où il existe plusieurs sources d’identité (par exemple, LDAP, Active Directory, les utilisateurs / groupes locaux de Qumulo), il peut être difficile de déterminer qui est qui à cause de la manière dont les utilisateurs sont. stocké et identifié en interne.

Avec les autorisations entre protocoles, Qumulo a introduit l'équivalence d'ID, qui utilise POSIX UID / GID en tant qu'identificateur commun entre les sources d'identité: Active Directory avec extensions POSIX ou 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 une personne et à quels groupes elle appartient.

Affichage du mode POSIX

Rappelons maintenant que Qumulo stocke les autorisations 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 d'un fichier donné, nous les générons à partir d'une liste QACL. Ceci est simple lorsque la liste QACL spécifie uniquement les administrateurs qui correspondent exactement à l'utilisateur / au groupe / tout le monde POSIX, mais lorsqu'il y a d'autres administrateurs "supplémentaires", cela devient plus compliqué.

Autoriser le propriétaire du fichier à lire
AUTORISER le propriétaire du groupe de fichiers en lecture
PERMETTRE à tous de 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 le propriétaire du fichier à lire
AUTORISER le propriétaire du groupe de fichiers en lecture
PERMETTRE à tous de lire
AUTORISE alice à lire, exécuter, écrire 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 a décidé de faire, c’est faire un compromis: Qumulo effectue des contrôles d’équivalence d’ID, la moins chère des deux opérations, pour voir si une ACE «supplémentaire» est réellement extra ou si elle est le propriétaire du fichier, mais ajoute autrement. les autorisations du dépositaire supplémentaire sur le bit Tout le monde. En supposant qu'alice ne soit pas le propriétaire du fichier dans la liste de contrôle d'accès ci-dessus, lors de la déclaration 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.

DENY alice read, prendre possession (Object inherit)
DENY charlie exécuter / traverse
PERMET Charlie de lire, d’écrire le fichier
PERMETTRE au groupe de charlie de lire
ALLOW Tout le monde lit le contenu
ALLOW bob read, write (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:

DENY alice prendre possession
DENY alice en lecture, en prendre possession (Object inherit, inherit-only)
AUTORISE charlie à lire, exécuter / traverser
AUTORISE le groupe de charlie à lire, exécuter / traverse
ALLOW Tout le monde lit, exécute / traverse
ALLOW bob read, write (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?

DENY alice read, prendre possession (Object inherit)

est devenu

DENY alice prendre possession
DENY alice en lecture, en prendre possession (Object inherit, inherit-only)

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

Les autorisations entre protocoles sont un mode d’autorisation, mais cela signifie en réalité qu’il s’agit d’un ensemble de nombreuses décisions prises par l’équipe Qumulo afin de répondre au mieux aux besoins des utilisateurs de Qumulo. Il n’existe pas de réponse parfaite à ce problème, mais en utilisant ID Equivalence, en choisissant de ne pas masquer les accès existants dans les bits de mode et en affectant de manière sélective les QACL lors du changement de mode POSIX et lors de la création, les autorisations inter-protocoles offrent une option à nos utilisateurs cela est simple, ne nécessite aucune configuration et fonctionne simplement.

Partager avec votre réseau