Wenn es um den Dateidatenzugriff mit mehreren Protokollen geht, dreht sich eine der Herausforderungen, die Qumulo löst, um Workflows mit gemischten Protokollen. Verwalten dieser Workflows, bei denen Benutzer über beide auf dieselben Dateien zugreifen NFS und SMB Protokolle, ist der Umgang mit Dateien Berechtigungen.
POSIX-Benutzer, die über NFS auf ihre Dateien zugreifen, erwarten ein anderes Berechtigungsverhalten als Windows-Benutzer, die über SMB auf ihre Dateien zugreifen. Um einen möglichst reibungslosen Workflow für Kunden in Multiprotokollumgebungen zu schaffen, hat Qumulo automatisiert Protokollübergreifende Berechtigungen (XPP) Funktionen, die es Benutzern ermöglichen, nahtlos über Computerplattformen und Netzwerkprotokolle hinweg zu arbeiten. Dies ermöglicht Benutzern auf Windows-, Linux- und macOS-Plattformen eine sichere Zusammenarbeit ohne aufwändige Berechtigungssicherungen und Vererbungsschemata.
XPP ist ein Berechtigungsmodus, der aus vielen Entscheidungen besteht, die von vielen Ingenieuren im Laufe von mehr als einem Jahr getroffen wurden. Es behebt inhärente Inkompatibilitäten zwischen POSIX- und NT-Berechtigungen, um Benutzern mit mehreren Protokolldateien eine möglichst nahtlose Berechtigungserfahrung zu bieten. Was machte dieses Problem so schwer zu lösen?
Als Benutzer von Dateisystemen neigen wir dazu, nicht zu viel über Berechtigungen nachzudenken – wir erwarten einfach, dass sie funktionieren. Aber wenn Berechtigungen „einfach funktionieren“ müssen, müssen Sie aus technischer Sicht viel nachdenken, wenn Sie zwei völlig unterschiedliche Protokolle mit unterschiedlichen Erwartungen haben, die in derselben Umgebung arbeiten.
POSIX vs. NT-Berechtigungen
Zuerst ein wenig Hintergrund. NT-Berechtigungen sind viel differenzierter als POSIX-Berechtigungen. POSIX-Berechtigungen werden durch Modusbits dargestellt. Sie haben diese schon einmal gesehen, wenn Sie jemals stat oder ls -l auf der Befehlszeile ausgeführt haben. Bits im POSIX-Modus können Rechte zum Lesen, Schreiben und Ausführen von Dateien/Verzeichnissen für den Dateibesitzer, den Gruppenbesitzer und alle anderen ausdrücken.
| Lesen Sie mehr | Schreiben | Ausführen | |
| Mappen | Datei lesen | Anhängen, ändern | Datei ausführen |
| Verzeichnisse | Verzeichnis auflisten | Kinder erstellen/umbenennen/löschen | Traverse-Verzeichnis (Kinder anschauen) |
In der POSIX-Welt gibt es drei grundlegende Berechtigungen, die unterschiedliche Bedeutungen haben, wenn sie auf Dateien und Verzeichnisse angewendet werden.
Auf der anderen Seite werden NT-Berechtigungen dargestellt durch Zugriffssteuerungslisten (ACLs). Eine ACL besteht aus einer oder mehreren Zugriffskontrolleinträge (ACEs), die jeweils einen Treuhänder, den Benutzer/die Gruppe, für die sie gilt, und eine Reihe von Rechten enthalten, die dem Treuhänder erlaubt oder verweigert werden.
So könnte beispielsweise ein ACE etwas in der Art von DENY bob read ausdrücken.
Einige wichtige Punkte zu ACLs:
- ACLs werden der Reihe nach ausgewertet. Der erste ACE in einer ACL, der auf einen Treuhänder angewendet wird, gewinnt alle nachfolgenden ACEs, die für diesen Treuhänder gelten können.
- Die möglichen Rechte in Windows sind differenzierter als nur Lesen, Schreiben und Ausführen – insgesamt gibt es 14 mögliche Rechte, darunter ein „Vollzugriffsrecht“, das den 13 anderen Rechten zusammengenommen entspricht.
- ACLs gelten pro Datei/Verzeichnis, und Einträge können von übergeordneten Verzeichnissen an ihre untergeordneten Verzeichnisse weitergegeben werden. Wir nennen ACEs, die von übergeordneten Verzeichnissen weitergegeben wurden, „geerbt“ und ACEs, die ansonsten direkt auf eine fragliche Datei angewendet wurden, „explizit“. ACEs haben Flags, die angeben, wie und ob sie vererbt werden.
- Windows erzwingt das Konzept einer kanonischen ACL, das die Reihenfolge vorgibt, in der explizite und geerbte ACEs in einer ACL erscheinen sollen. Eine kanonisch geordnete ACL sieht wie folgt aus:
Explizite VERWEIGERUNGEN
Explizite ERLAUBT
Vererbte DENYs
Geerbte ERLAUBT
Dieser Screenshot oben zeigt die möglichen Berechtigungen in Windows.
Qumulo File Data Platform und protokollübergreifende Berechtigungen
Wie geht Qumulo angesichts der ziemlich drastischen Unterschiede zwischen POSIX-Modus-Bits und NT-ACLs mit Berechtigungen um? Wir haben unsere eigene Version der ACL, die als QACL bezeichnet wird. Es ordnet fast 1:1 der NT-ACL zu und speichert und versteht eine Obermenge der Rechte, die in POSIX und Windows ausgedrückt werden können.
Inkonsistenzen zwischen den NT- und POSIX-Berechtigungsmodellen lassen sich auf vier Operationen reduzieren: Modusbits anzeigen, Berechtigungen ändern, Dateien erstellen und den Besitzer einer Datei ändern. In diesem Beitrag werden wir uns speziell mit der Anzeige von Modus-Bits und dem Ändern von Berechtigungen befassen, um zu verstehen, wie XPP diese Inkonsistenzen löst.
Bevor Sie sich eingehender mit bestimmten Berechtigungsvorgängen befassen, ist es wichtig zu beachten, dass eine der zugrunde liegenden Herausforderungen von XPP darin besteht, den oder die Benutzer zu bestimmen, für die ein Satz von Berechtigungen gilt. Dies gilt unabhängig vom Protokoll: hochverfügbares verteiltes Dateisystem wie Die Dateidatenplattform von Qumulo, wo potenziell mehrere Identitätsquellen vorhanden sind (z. B. LDAP, Active Directory, lokale Benutzer/Gruppen von Qumulo), kann es aufgrund der internen Speicherung und Identifizierung der Benutzer schwierig sein, zu erkennen, wer wer ist.
Mit XPP führte Qumulo die ID-Äquivalenz ein, die POSIX UID/GID als gemeinsamen Bezeichner für alle Identitätsquellen verwendet: Active Directory mit POSIX-Erweiterungen oder benutzerdefinierten Zuordnungen, OpenLDAP und lokale Benutzer/Gruppen von Qumulo. Dadurch ist es möglich, diese Werte zu vergleichen, um herauszufinden, wer jemand ist und zu welchen Gruppen er gehört.
Anzeige des POSIX-Modus
Denken Sie daran, dass Qumulo Berechtigungen in Form von QACLs speichert. Das bedeutet, dass wir den POSIX-Modus nicht als Wert auf der Festplatte speichern. Wenn Benutzer, die über NFS auf Qumulo zugreifen, die Modusbits für eine bestimmte Datei sehen möchten, generieren wir sie aus einer QACL. Dies ist einfach, wenn die QACL nur Trustees angibt, die genau mit POSIX-Benutzer/-Gruppe/jeder übereinstimmen, aber wenn es andere, „zusätzliche“ Trustees gibt, wird es komplizierter.
Erlaube dem Dateibesitzer, zu lesen
Dateigruppenbesitzer lesen zulassen
ERLAUBEN, dass jeder liest
In dieser einfachen ACL ist leicht zu erkennen, welcher POSIX-Modus angezeigt werden soll. Der Besitzer, der Gruppenbesitzer und Jeder haben alle Leserechte, was 444 bedeutet. Aber was wäre, wenn unsere ACL so aussehen würde?
Erlaube dem Dateibesitzer, zu lesen
Dateigruppenbesitzer lesen zulassen
ERLAUBEN, dass jeder liest
Erlaube Alice, Datei zu lesen, auszuführen, zu schreiben
Wie gehen wir mit dem „zusätzlichen“ ACE um, das auf Alice zeigt? Um den möglichst genauen POSIX-Modus anzuzeigen, müssen wir wissen, ob alice der Dateibesitzer ist und/oder zur Gruppe der Datei gehört. Das Herausfinden dieser beiden Informationen ist möglich, aber teuer und würde einen großen Leistungseinbruch für die recht häufige Operation der Anzeige des POSIX-Modus verursachen.
Um herauszufinden, ob Alice in der Dateigruppe ist, müssten wir insbesondere eine rekursive Erweiterung der Gruppenmitgliedschaft sowohl für die Dateigruppe als auch für Alice durchführen und alle Identitätsquellen abfragen, um herauszufinden, ob Alice der Dateibesitzer ist.
Stattdessen hat sich unser Engineering-Team entschieden, einen Kompromiss einzugehen: Qumulo führt ID-Äquivalenzprüfungen durch, die kostengünstigere der beiden Operationen, um zu sehen, ob ein "zusätzlicher" ACE tatsächlich ein Extra ist oder ob es der Dateibesitzer ist, aber sonst fügt die Berechtigungen des zusätzlichen Treuhänders zum Bit Jeder hinzu. Unter der Annahme, dass Alice nicht der Dateibesitzer in der obigen ACL ist, würde ein Benutzer beim Angeben der Datei das Modusbit 447 sehen, wobei die Rechte von Alice in das Jeder-Bit gefaltet sind.
Dies mag auf den ersten Blick ungewöhnlich erscheinen – es stimmt nicht wirklich, dass jeder über Lese-, Schreib- und Ausführungsberechtigungen für die Datei verfügt. Stellen Sie sich jedoch vor, dass wir stattdessen 444 als Modus für diese Datei anzeigen. Jemand, der sich diesen Modus ansieht, könnte annehmen, dass niemand Schreib- oder Ausführungsberechtigungen hatte. Aber Alice hat diese Berechtigungen, und den Benutzer glauben zu lassen, dass es anders geht, stellt ein Sicherheitsrisiko dar. Indem der freizügigste Modus für eine bestimmte QACL angezeigt wird, lässt Qumulo Benutzern, die sich Berechtigungen über NFS ansehen, wissen, dass jemand, wenn nicht jeder, die im Jeder-Bit angegebenen Berechtigungen hat.
Ändern des POSIX-Modus
Ein weiteres Problem, auf das das Team stieß, als es das Problem des Zusammenwirkens von NT- und POSIX-Berechtigungen anging, war der Umgang mit einem chmod, der über NFS kommt. Denken Sie daran, dass QACLs potenziell über POSIX-Lese-/Schreib-/Ausführungsrechte hinaus sowie zusätzliche Trustees und komplizierte Vererbungsschemata haben.
DENY alice lesen, Besitz übernehmen (Objekt erben)
DENY Charlie ausführen/überqueren
Erlaube Charlie zu lesen, Datei zu schreiben
Erlaube Charlies Gruppe zu lesen
ERLAUBEN, dass jeder Inhalt lesen kann
Erlaube bob lesen, schreiben (nur erben)
Für die Datei, für die diese QACL gilt, ist charlie der Eigentümer. Das Flag inherit des Objekts in Alices ACE bedeutet, dass es an alle untergeordneten Dateien/Verzeichnisse weitergegeben werden sollte, und das Flag inherit only in Bob bedeutet, dass es weitergegeben werden sollte und dass es die Berechtigungen von Bob für die aktuelle Datei nicht beeinträchtigen sollte. Wie ändern wir diese QACL, wenn jemand chmod 555 darauf ausführt?
Mit XPP hat das Team einen Algorithmus entwickelt, der sowohl den angeforderten Modus als auch die bereits vorhandene QACL berücksichtigt und die QACL so manipuliert, dass sie die Absicht des chmod berücksichtigt und gleichzeitig die Vererbungsstruktur der bereits vorhandenen QACL beibehält. Als Beispiel wäre die resultierende QACL nach der Anwendung des Modus 555 auf den obigen:
DENY Alice übernimmt das Eigentum
DENY alice lesen, Besitz übernehmen (Objekt erben, nur erben)
ERLAUBTE Charlie lesen, ausführen/traversieren
Erlaube Charlies Gruppe zu lesen, auszuführen/durchzugehen
ERLAUBEN Jeder lesen, ausführen/traversieren
Erlaube bob lesen, schreiben (nur erben)
Was ist hier passiert? Die Rechte wurden geändert, um den angeforderten Modus 555 widerzuspiegeln. Beachten Sie auch, dass es in der vorherigen QACL einen DENY-Eintrag für den Dateibesitzer gab, der nicht mehr existiert, weil er dem chmod widersprach.
Schauen wir uns nun die anderen ACEs an. Warum gibt es jetzt zwei ACEs für alice?
DENY alice lesen, Besitz übernehmen (Objekt erben)
Vorher Nachher
DENY Alice übernimmt das Eigentum
DENY alice lesen, Besitz übernehmen (Objekt erben, nur erben)
Der erste ACE behält die verweigerte Berechtigung für ein Nicht-POSIX-Recht im ursprünglichen ACE (Inhaberschaft übernehmen ist ein reines SMB-Konzept), und der zweite ist nur eine Kopie des ersten, die als Nur vererben markiert ist, damit es möglich ist an untergeordnete Dateien und Verzeichnisse weitergegeben, ohne die aktuelle Datei zu beeinflussen. Da bobs ACE anfangs nur vererben war, hat es sowieso keinen Einfluss auf die Berechtigungen in dieser Datei und bleibt nach dem chmod gleich.
Fazit: Vereinfachung des Datenzugriffs auf Multiprotokolldateien für Benutzer
Protokollübergreifende Berechtigungen sind a Berechtigungsmodus, aber was das wirklich bedeutet, ist, dass es eine Sammlung von vielen Entscheidungen ist, die das Qumulo-Team getroffen hat, um den Bedürfnissen der Benutzer von Qumulo am besten gerecht zu werden.
Es gibt keine perfekte Antwort, wenn es um dieses Problem geht. Durch die Verwendung von ID-Äquivalenz, die Entscheidung, den bestehenden Zugriff in den Modusbits nicht zu verbergen, und die selektive Beeinflussung von QACLs beim Ändern des POSIX-Modus und beim Erstellen, bietet Cross Protocol Permissions unseren Benutzern eine einfache Option, die keine Konfiguration erfordert und nur funktioniert.
Erfahren Sie mehr
- Verstehen Sie, wie unsere Datendienste machen es Ihnen einfacher, große Mengen an Dateidaten zu verwalten.
- Lesen Sie die technische Übersicht und erfahren Sie mehr über die leistungsstarke Dateidatenplattform von Qumulo.
Kontakt
- Machen Sie eine Probefahrt. Testen Sie Qumulo in unseren neuen interaktiven Hands-On Labs oder fordern Sie eine Demo oder eine kostenlose Testversion an.
- Abonnieren Sie den Qumulo-Blog für Kundengeschichten, technische Einblicke, Branchentrends und Produktneuigkeiten.
