...
zu verwenden, die sich allerdings in ihrer Syntax von nfs_setfacl
unterscheiden, und eventuell nicht alle Funktionen abbilden. (Siehe dazu man mmeditacl
, man mmputacl
, man mmgetacl
, oder https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.1/com.ibm.spectrum.scale.v4r21.doc/bl1adm_mmputacl.htm)
Syntax
...
Die ACLs bestehen aus mehreren Einträgen, welche jeweils die Berechtigungen für einen Nutzer oder eine Nutzergruppe spezifizieren. Zusätzlich zu den Berechtigungen kann die Funktionsweise der ACLs durch einen Typ oder verschiedene Flags beeinflusst werden. Die vollständige Syntax für das auf dem Login-Knoten verwendete nfs4_setfacl
lautet:
Codeblock | ||||
---|---|---|---|---|
| ||||
type:flags:principal:permissions |
Typ
Es gibt vier verschiedene Typen an ACL-Einträgen, die die Bedeutung der Berechtigungen regeln:
...
Für uns sind nur die ersten beiden Typen relevant.
Flags
Flags steuern z.B. die Weitergabe / Vererbung der ACLs an Unterordner / Dateien, oder erlauben es, eine Nutzergruppe statt einem einzelnen Nutzer zu spezifizieren
...
Zielnutzer / -gruppe
"Principal" ist der Nutzer (oder die Gruppe bei Verwendung von Flag g
) für den die Berechtigungen gelten. Es gibt zusätzlich drei Sondertypen: OWNER@
, GROUP@
und EVERYONE@
, die den POSIX-Berechtigungen Besitzer / Gruppe / Andere entsprechen.
Berechtigungen
Berechtigungen steuern die tatsächlichen Berechtigungen des jeweiligen ACL-Eintrags.
...
Ein paar Beispiele
...
Vollzugriff ohne ACL ändern
...
Die Verwendung der ACLs unterscheidet sich auf dem Login-Knoten und den Compute-Knoten bzw. Storage-Knoten. Um für beide Varianten eine optimale Dokumentation zu gewährleisten, existiert für beide Systeme eine eigene Anleitung:
Tabelle des Content-Berichts | ||||||||
---|---|---|---|---|---|---|---|---|
|
Standard-ACLs
Standardmäßig werden keine Berechtigungen vererbt. Jede neue Datei / Unterordner wird standardmäßig mit den Standard-ACLs initialisiert, die wie folgt lauten:
Codeblock | ||||
---|---|---|---|---|
| ||||
A::OWNER@:rwaDxtTnNcCoy
A::GROUP@:rxtncy
A::EVERYONE@:rxtncy |
Dateien / Ordner mit einzelnen Nutzern freigeben
ACLs können sehr gut dazu verwendet werden, um bestimmte Dateien oder Ordnern mit bestimmten Nutzern / Nutzergruppen freizugeben. Eine vollständige ACL für einen Ordner mit zusätzlichen Berechtigungen für einen weiteren Nutzer und Vererbung für zukünftige Unterordner / Dateien könnte beispielsweise so aussehen:
Codeblock | ||||
---|---|---|---|---|
| ||||
A:fd:OWNER@:rwaDdxtTnNcCoy
A:fd:GROUP@:rxtncy
A:fd:EVERYONE@:tcy
A:fd:EigenerNutzername:rwaDxtncy
A:fd:NeuerNutzername:rwaDxtncy |
Warnung | ||
---|---|---|
| ||
Beim Hinzufügen von Regeln mit Vererbung ( Außerdem muss neben der Regel für den neuen Benutzer ebenfalls eine Regel für den eigenen Benutzer hinzugefügt werden. Normalerweise ist der eigene Benutzer über |
Siehe auch
Siehe auch: man nfs4_acl
Weitere Anleitungen: https://www.rz.uni-augsburg.de/service/cfs/FAQ/acl-details/
Syntax (Compute-Nodes, Storage-Knoten)
Auf den Compute-Nodes und den Storage-Knoten kommen die Tools
Codeblock | ||||
---|---|---|---|---|
| ||||
mmeditacl
mmputacl
mmgetacl
mmdelacl |
zum Einsatz, die sich in ihrer Verwendung von den Tools auf dem Login-Knoten grundlegend unterscheiden. Die unterstützen Berechtigungen und Regelformen sind natürlich identisch zu der oben beschriebenen Variante. Allerdings wird statt einer auf flags basierenden Syntax eine tabellenbasierte Form verwendet:
Codeblock | ||||
---|---|---|---|---|
| ||||
special:owner@:rwxc:allow
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
user:Nutzername:--x-:allow:FileInherit:DirInherit
(-)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL (-)READ_ATTR (-)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED |
Je drei Zeilen bilden gemeinsam eine Regel. In der ersten Zeile wird zunächst der Zielnutzer / die Zielgruppe spezifiziert: special:owner@
bezeichnet beispielsweise den "Spezialnutzer" owner@
, also den jeweiligen Eigentümer einer Datei. Analog dazu existieren special:group@
oder special:everyone@
. user:Nutzername
betrifft den Nutzer mit dem entsprechenden Nutzernamen:
...
Anschließend folgen 4 Zeichen, die die direkten Berechtigungen des jeweiligen Nutzers / der jeweiligen Gruppe repräsentieren. Diese müssen allerdings nicht manuell aktualisiert werden, eine Bearbeitung der Berechtigungen in den runden Klammern wie unten beschrieben genügt dabei völlig, die 4 Berechtigungen stellen nur eine Art Zusammenfassung da, die automatisch aktualisiert wird. Dabei existieren die folgenden Belegungen:
...
An dritter Stelle wird der Regeltyp angegeben. Hier sollte allow verwendet werden, da Berechtigungen über Erlaubnisse und nicht über Verbote definiert werden sollten.
Zuletzt folgen weitere Flags, die das Verhalten der Regel beeinflussen, z.B. die Vererbung auf Dateien und Unterordner. Hierbei existieren beispielsweise folgende Flags:
...
Anschließend folgen zwei Zeilen mit den jeweiligen Berechtigungen für den angegebenen Nutzer. Die Berechtigungen sind in diesem Fall benannt und mit runden Klammern versehen. Ein X innerhalb der Klammer bedeutet, dass die jeweilige Berechtigung erteilt ist, bei einem - hat der entsprechende Nutzer / die entsprechende Gruppe die jeweilige Berechtigung nicht.
Ein paar Beispiele
Standard-ACLs
Standardmäßig werden keine Berechtigungen vererbt. Jede neue Datei / Unterordner wird standardmäßig mit den Standard-ACLs initialisiert, die wie folgt lauten:
Codeblock | ||||||
---|---|---|---|---|---|---|
| ||||||
#NFSv4 ACL
#owner:luros101
#group:ngs-admins
special:owner@:rwxc:allow
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
special:group@:r-x-:allow
(X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
special:everyone@:r-x-:allow
(X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED |
Dateien / Ordner mit einzelnen Nutzern freigeben
ACLs können sehr gut dazu verwendet werden, um bestimmte Dateien oder Ordnern mit bestimmten Nutzern / Nutzergruppen freizugeben. Eine vollständige ACL für einen Ordner mit zusätzlichen Berechtigungen für einen weiteren Nutzer und Vererbung für zukünftige Unterordner / Dateien könnte beispielsweise so aussehen:
Codeblock | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
#NFSv4 ACL
#owner:luros101
#group:ngs-admins
special:owner@:rwxc:allow:FileInherit:DirInherit
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
special:group@:rwx-:allow:FileInherit:DirInherit
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (X)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
special:everyone@:rwx-:allow:FileInherit:DirInherit
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (X)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
user:EigenerNutzername:rwxc:allow:FileInherit:DirInherit
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
user:NeuerNutzername:rwx-:allow:FileInherit:DirInherit
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (X)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED |
...
title | Bestehende Regeln anpassen! |
---|
Beim Hinzufügen von Regeln mit Vererbung (FileInherit:DirInherit
) wie in diesem Beispiel erforderlich, ist es wichtig, dass auch die bestehenden Regeln um die Vererbungs-Flags FileInherit:DirInherit
erweitert werden. Andernfalls werden nur die Berechtigungen für die hinzugefügten Nutzer vererbt, der Eigentümer der Dateien hat anschließend keinen Zugriff mehr.
...