Rechercher
Fermez ce champ de recherche.

Gestion des flux de travail d'accès aux données de fichiers multi-protocoles avec des autorisations inter-protocoles

Rédigé par:

En ce qui concerne l'accès aux données de fichiers multiprotocoles, l'un des défis résolus par Qumulo se concentre sur les flux de travail à protocoles mixtes, dans lesquels les utilisateurs accèdent aux mêmes fichiers via les protocoles NFS3, NFSv4.1 et SMB. Un défi majeur dans des situations comme celle-ci est de savoir comment gérer les autorisations de fichiers.

Les utilisateurs NFS3 accédant à leurs fichiers s'attendent à un modèle d'autorisations différent de celui des utilisateurs Windows accédant à leurs fichiers via SMB ou NFSv4.1. Afin de créer le flux de travail le plus fluide possible pour les clients dans des environnements multi-protocoles, Qumulo a développé un système unique Autorisations inter-protocoles (XPP) qui permet aux utilisateurs des plates-formes Windows, Linux et macOS de collaborer en toute sécurité sans recourir à des sauvegardes d'autorisations et à des schémas d'héritage élaborés.

Le modèle d'autorisations multiprotocoles de Qumulo résout les incompatibilités inhérentes entre les autorisations POSIX et Access Control List (ACL) pour fournir aux utilisateurs dans des environnements hétérogènes une expérience d'autorisations aussi transparente que possible, quel que soit le protocole qu'ils utilisent.

Qu’est-ce qui rend ce problème si difficile à résoudre ?

Les utilisateurs de systèmes de fichiers ont tendance à ne pas trop penser aux autorisations ; nous nous attendons simplement à ce qu'ils fonctionnent. Mais avoir des autorisations « fonctionne » nécessite beaucoup de réflexion du point de vue de l'ingénierie lorsque vous disposez de deux protocoles complètement différents avec des attentes distinctes fonctionnant dans le même environnement.

Autorisations POSIX et ACL

Les autorisations ACL sont beaucoup plus fines que les autorisations POSIX. Les autorisations POSIX sont représentées par des bits de mode qui sont intégrés dans les métadonnées de chaque fichier et répertoire d'un ensemble de données POSIX. Vous avez déjà vu ça si vous avez déjà couru stat or ls -l à partir de la ligne de commande. Les bits du 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 tout le monde.

Dans le monde POSIX, il existe trois niveaux d'autorisation de base, et ils signifient des choses différentes lorsqu'ils sont appliqués aux fichiers et aux répertoires.

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)

Les autorisations SMB et NFSv4.1 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), dont chacun contient un fiduciaire, l'utilisateur/le groupe auquel il s'applique et un ensemble de droits que le fiduciaire est autorisé ou refusé.

Ainsi, par exemple, un ACE peut exprimer quelque chose du type DENY Read au compte utilisateur nommé bob.

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. Les ACE transmis à partir des répertoires parents sont appelés « hérités » et les ACE appliqués directement à un fichier en question sont « explicites ». Les ACE ont des indicateurs qui indiquent comment et s'ils sont hérités.
  • 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

Autorisations inter-protocoles sur Qumulo

Compte tenu des différences assez significatives entre les bits du mode POSIX et les ACL, comment Qumulo gère-t-il les autorisations ? Nous avons notre propre version de l'ACL, appelée QACL. Il correspond presque 1:1 à l'ACL standard de l'industrie, et il stocke et comprend un sur-ensemble de droits qui peuvent être exprimés à la fois dans POSIX et Windows.

Les incohérences entre les modèles d'autorisations ACL et POSIX peuvent se résumer à quatre opérations : afficher les bits de mode, modifier les autorisations, créer des fichiers et changer le 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 Qumulo résout ces incohérences.

Avant d'approfondir les opérations d'autorisations spécifiques, il est important de noter que l'un des défis sous-jacents auxquels XPP, le modèle multiprotocole de Qumulo, répond est de savoir comment déterminer le ou les utilisateurs auxquels s'applique un ensemble d'autorisations. Cela est vrai quel que soit le protocole : dans un système de fichiers distribué hautement disponible comme Qumulo, lorsqu'il existe potentiellement plusieurs sources d'identité (par exemple, LDAP, Active Directory, utilisateurs/groupes locaux de Qumulo), il peut être difficile de savoir 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 entre 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 une personne et de quels groupes elle est membre.

Affichage du mode POSIX

Rappelons maintenant que Qumulo stocke les autorisations sous forme de QACL. Cela signifie que nous ne stockons pas le mode POSIX comme valeur sur le disque. Lorsque les utilisateurs accédant à Qumulo via NFS souhaitent voir les bits de mode d'un certain fichier, nous les générons à partir d'un QACL. Cela est simple lorsque le QACL spécifie uniquement les administrateurs qui s'alignent exactement sur les utilisateurs/groupes/tout le monde POSIX, mais lorsqu'il y a d'autres administrateurs « supplémentaires », cela devient plus compliqué.

ALLOW file owner read
ALLOW file group owner read
ALLOW Everyone read

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?

 

ALLOW file owner read something
ALLOW file group owner read something
ALLOW Everyone read something
ALLOW alice read read, execute, write file

Comment gérer l’ACE « supplémentaire » qui pointe vers Alice ? Afin d'afficher le mode POSIX le plus précis possible, nous devons savoir si Alice est propriétaire du fichier et/ou appartient au groupe du fichier. Trouver ces deux informations est possible, mais coûteux, et entraînerait une baisse importante des 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.

L'approche Qumulo consiste à effectuer des vérifications d'équivalence d'identité, la moins coûteuse des deux opérations, pour voir si un ACE « supplémentaire » est réellement supplémentaire, ou s'il s'agit du propriétaire du fichier, mais ajoute sinon les autorisations du fiduciaire 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 intégrés dans le bit Tout le monde.

Cela peut sembler inhabituel au premier abord : il n'est pas vrai que tout le monde dispose des autorisations de lecture, d'écriture et d'exécution sur le fichier. Imaginez, cependant, que nous indiquions à la place 444 comme mode pour ce fichier. Quelqu'un qui examine ce mode pourrait supposer que personne ne disposait d'autorisations d'écriture ou d'exécution. Mais Alice dispose de ces autorisations, et faire croire à l'utilisateur le contraire introduit un risque de sécurité. En affichant le mode le plus permissif possible pour un QACL donné, Qumulo permet aux utilisateurs qui consultent les autorisations POSIX de savoir que quelqu'un, sinon tout le monde, dispose des autorisations indiquées dans le bit Tout le monde.

Changer le mode POSIX

Un autre problème lié à la collaboration entre les ACL et les autorisations POSIX est la manière de gérer un chmod arrivant via NFS. N'oubliez pas que les QACL ont potentiellement des droits au-delà de la lecture/écriture/exécution POSIX, ainsi que des administrateurs supplémentaires et des schémas d'héritage compliqués.

 

DENY alice read read, take ownership (Object inherit)
DENY charlie read execute / traverse
ALLOW charlie read read, write file
ALLOW charlie's group read read
ALLOW Everyone read read contents
ALLOW bob read read, write (Inherit-only)

Pour le fichier auquel cette QACL s'applique, Charlie est le propriétaire. L'indicateur d'héritage d'objet sur l'ACE d'Alice signifie qu'il doit être transmis à tous les fichiers/répertoires enfants, et l'indicateur d'héritage uniquement sur celui de Bob signifie qu'il doit être transmis et qu'il ne doit pas affecter les autorisations de Bob sur le fichier actuel. Comment pouvons-nous modifier ce QACL lorsque quelqu'un effectue un chmod 555 dessus ?

Avec XPP, nous utilisons un algorithme qui examine à la fois le mode demandé et le QACL préexistant, et manipule le QACL pour honorer l'intention du chmod tout en préservant la structure d'héritage du QACL préexistant. A titre d'exemple, le QACL résultant après application du mode 555 à celui ci-dessus serait :

DENY alice read take ownership
DENY alice read read, take ownership (Object inherit, inherit-only)
ALLOW charlie read read, execute / traverse
ALLOW charlie's group read read, execute / traverse
ALLOW Everyone read read, execute / traverse
ALLOW bob read read, write (Inherit-only)

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 read, take ownership (Object inherit)

Avant après

 

DENY alice read take ownership
DENY alice read read, take ownership (Object inherit, inherit-only)

Le premier ACE préserve l'autorisation refusée sur un droit non-POSIX dans l'ACE d'origine (la prise de propriété est un concept ACL uniquement), et le second est simplement une copie du premier, marqué comme héritant uniquement afin qu'il puisse être transmis aux fichiers et répertoires enfants sans affecter le fichier actuel. Étant donné que l'ACE de Bob était uniquement hérité au départ, cela n'affecte de toute façon pas les autorisations dans ce fichier et reste le même après le chmod.

The Bottom Line: Simplifier l'accès aux données de fichiers multiprotocole pour les utilisateurs

Le modèle d'autorisations inter-protocoles de Qumulo est une approche unique pour gérer l'accès multi-protocole aux données communes pour les clients basés sur POSIX et ACL, offrant à nos utilisateurs une option simple, ne nécessite aucune configuration et fonctionne simplement.

En savoir plus

Contactez nous !

  • Faites un essai routier. Démo Qumulo dans nos nouveaux laboratoires interactifs interactifs ou demandez un essai gratuit.
  • Abonnez-vous au blog Qumulo pour les témoignages de clients, les informations techniques, les mises à jour de l'industrie et les nouvelles sur les produits

Articles Similaires

Remonter en haut