Suche

NFSv4 ACLs im Detail


NFSv4 ACLs

NFSv4-ACLs bestehen aus Einträgen (ACEs, Access Control Entries) der folgenden Form, die unter AIX bzw. Linux unterschiedlich aussieht:

    <wtype>:<who>:<type> <permissions> <flags>	(AIX)
    <type>:<flags>:<who>:<permissions>		(Linux)

Da auch die Inhalte der Felder bei AIX und Linux nicht identisch sind, sind im folgenden immer die entsprechenden Werte für beide Systeme angegeben.

  • <who>

Im Feld <who> steht, auf welche Benutzer sich der ACE bezieht. Hier kann man entweder einen einzelnen Benutzer, eine Gruppe oder einen der drei speziellen Namen aus der folgenden Tabelle verwenden. Die speziellen Namen stehen für den Besitzer bzw. die Gruppe der Datei bzw. für alle Benutzer. Sie entsprechen den drei Gruppen der Unix Mode-Bits.

AIX Linux Beschreibung
(OWNER@) OWNER@ Besitzer der Datei
(GROUP@) GROUP@ Gruppe der Datei
(EVERYONE@) EVERYONE@ alle Benutzer

Unter Linux muß hierbei an jeden Benutzer- oder Gruppennamen @uni-augsburg.de angehängt werden (unter AIX geschieht das automatisch). uni-augsburg.de ist der Domain-Name für den idmapd, welcher für die Übersetzung zwischen Namen und Nummern zuständig ist. Da wir auf allen Clients die selbe Zuordnung verwenden, gibt es nur einen Domain-Namen. Bei den speziellen Namen ist der Domain-Name immer leer.

  • <wtype>

<wtype> kann einen der Werte u, g oder s annehmen und gibt an, ob es sich bei <who> um einen Benutzer (u), eine Gruppe (g) oder einen speziellen Namen (s) handelt. Bei Linux gibt es dieses Feld nicht. Stattdessen wird dort im <flags>-Feld ein g eingetragen, falls es sich bei <who> um einen Gruppennamen handelt. Benutzer- und spezielle Namen werden automatisch unterschieden.

  • <type>

<type> besteht aus genau einem Buchstaben, wobei es prinzipiell folgende Möglichkeiten gibt:

AIX Linux Name
a A allow
d D deny
l U audit (nicht implementiert)
u L alarm (nicht implementiert)

Da bei Verwendung von "deny"-ACEs die Reihenfolge, in der die ACEs ausgewertet werden, bei Windows im Gegensatz zu AIX und Linux unterschiedlich ist, wird von ihrer Benutzung abgeraten. Kurz gesagt: <type> sollte immer a bzw. A sein.

  • <flags>

<flags> kann aus einer beliebigen Kombination folgender Werte bestehen:

AIX Linux mmgetacl (gpfs) Name (laut nfs4_getfacl -H)
fi f FileInherit file-inherit
di d DirInherit directory-inherit
ni p no-propagate-inherit (nicht implementiert)
oi i InheritOnly inherit-only
S successful-access (nicht implementiert)
F failed-access (nicht implementiert)
g group (gibt an, daß <who> der Name einer Gruppe ist)
O Inherited inherited ACE (AIX/Linux/gpfs/RFC: undokumentiert)

"file-inherit" bzw. "directory-inherit" bewirken, daß ein ACE an Dateien bzw. Unterverzeichnisse vererbt wird. "no-propagate-inherit" sorgt dafür, daß ein ACE ohne Vererbungs-Flags weitergegeben wird. "inherit-only" bedeutet, daß ein ACE nur vererbt wird, sich aber nicht auf sein eigenes Verzeichnis auswirkt.

  • <permissions>

Die einzelnen Zugriffsberechtigungen sind in folgender Tabelle zusammengefaßt:

Name (laut nfs4_getfacl -H) AIX Linux mmgetacl (gpfs) Windows (en) Windows (de)
read-data / list-directory r r READ/LIST List Folder / Read data Ordner auflisten / Daten lesen
write-data / create-file w w WRITE/CREATE Create Files / Write Data Dateien erstellen / Daten schreiben
append-data / create-subdirectory p a MKDIR Create Folder / Append Data Ordner erstellen / Daten anhängen
delete-child (directories only) D D DELETE_CHILD Delete Subfolders and Files Unterordner und Dateien löschen
delete d d DELETE Delete Löschen
execute x x EXEC/SEARCH Traverse Folder / Execute File Ordner durchsuchen / Datei ausführen
read-attrs a t READ_ATTR Read Attributed Attribute lesen
write-attrs A T WRITE_ATTR Write Attributes Attribute schreiben
read-named-attrs R n READ_NAMED Read Extendes Attributes erweiterte Attribute lesen
write-named-attrs W N WRITE_NAMED Write Extended Attributes erweiterte Attribute schreiben
read-ACL c c READ_ACL Read Permissions Berechtigungen lesen
write-ACL C C WRITE_ACL Change Permissions Berechtigungen ändern
write-owner o o CHOWN Take Ownership Besitz übernehmen
synchronize s y SYNCHRONIZE - -

Typische ACLs wie sie im CFS verwendet werden sind in folgender Tabelle zusammengefaßt (Linux-Notation):

Beschreibung Vollzugriff Vollzugriff -execute Vollzugriff -write-ACL Vollzugriff -write-ACL -execute OU-cfs-admins Durchgangs-Dir Dir = Freigabe
Verwendung owner@ home owner@ home owner@ & Gruppen share owner@ & Gruppen share share OU-d everyone@ everyone@
Vererbung directory-inherit file-inherit inherit-only directory-inherit file-inherit inherit-only - - -
Name (laut nfs4_getfacl -H)
read-data / list-directory r r r r r r -
write-data / create-file w w w w - - -
append-data / create-subdirectory a a a a - - -
delete-child (directories only) D D D D D - -
delete d d d d d - -
execute x - x - x x -
read-attrs t t t t t t t
write-attrs T T T T T - -
read-named-attrs n n n n n - -
write-named-attrs N N N N N - -
read-ACL c c c c c c c
write-ACL C C - - C - -
write-owner o o o o o - -
synchronize y y y y y - -

Konkret werden damit die default Rechte für leere Homeverzeichnisse und für die share Verzeichnisse einer OU gesetzt. Hier eine Beispiel-Ausgabe der ACLs für solche Verzeichnisse, aus Gründen der Kompaktheit in Linux/nfs4_getfacl Darstellung:

> nfs4_getfacl $HOME
A:d:OWNER@:rwaDdxtTnNcCoy
A:fi:OWNER@:rwaDdtTnNcCoy
A::EVERYONE@:tc
> nfs4_getfacl OU_DIR
A::EVERYONE@:rxtc
> nfs4_getfacl OU_DIR/OU_d
A:d:OWNER@:rwaDdxtTnNcoy
A:fi:OWNER@:rwadtTnNcoy
A:g:OU-cfs-admins@uni-augsburg.de:rDdxtTnNcCo
A::EVERYONE@:tc
> nfs4_getfacl OU_DIR/OU_h
A:d:OWNER@:rwaDdxtTnNcoy
A:fi:OWNER@:rwadtTnNcoy
A:dg:OU-m@uni-augsburg.de:rwaDdxtTnNcoy
A:fig:OU-m@uni-augsburg.de:rwadtTnNcoy
A:dg:OU-h@uni-augsburg.de:rwaDdxtTnNcoy
A:fig:OU-h@uni-augsburg.de:rwadtTnNcoy
A::EVERYONE@:tc
> nfs4_getfacl OU_DIR/OU_m
A:d:OWNER@:rwaDdxtTnNcoy
A:fi:OWNER@:rwadtTnNcoy
A:dg:OU-m@uni-augsburg.de:rwaDdxtTnNcoy
A:fig:OU-m@uni-augsburg.de:rwadtTnNcoy
A::EVERYONE@:tc
> nfs4_getfacl OU_DIR/OU_s
A:d:OWNER@:rwaDdxtTnNcoy
A:fi:OWNER@:rwadtTnNcoy
A:dg:OU-s@uni-augsburg.de:rwaDdxtTnNcoy
A:fig:OU-s@uni-augsburg.de:rwadtTnNcoy
A::EVERYONE@:tc
  • Anmerkungen
    • Die mittels Windows "Vollzugriff" vergebenen Rechte unterscheiden sich von den unter AIX/Linux mit chmod gesetzten mode bits rwx. Windows "Vollzugriff" unterscheidet nicht zwischen Dateien und Verzeichnisse und vergibt gleichermaßen die Rechte rwpRWxDaAdcCos (AIX-Darstellung) bzw. rwaDdxtTnNcCoy (Linux-Darstellung). Im Gegensatz dazu ergeben die mode bits rwx bei Dateien den ACE-Eintrag rwpxaAcCos (AIX) bzw. rwaxtTcCoy (Linux). Verzeichnisse erhalten zusätzlich zu Dateien noch das Recht D (Unterordner und Dateien löschen), d.h. rwpxDaAcCos (AIX) bzw. rwaDxtTcCoy(Linux).
      • Damit fehlen gegenüber "Vollzugriff" die folgenden Rechte bei mode bits rwx:
        • R (erweiterte Attribute lesen)
        • W (erweiterte Attribute schreiben)
        • d (Löschen)
        • D (Unterordner und Dateien löschen): fehlt nur bei Dateien
      • Windows zeigt für Dateien (zumindest in der GUI) das Recht D (Unterordner und Dateien löschen) nicht an, obwohl es bei "Vollzugriff" gesetzt ist.
    • Die Einträge einer ACL werden vom Server bei einem Zugriffsversuch von oben nach unten abgearbeitet. Dabei werden nur solche Einträge berücksichtigt, bei denen der zugreifende Benutzer zum <who>-Feld paßt. Wenn keine deny-Einträge darunter sind, hat der Benutzer genau die Berechtigungen, die in mindestens einem Eintrag erlaubt sind.
    • Bei Dateien sollte "write-data" nie ohne "write-attrs" gesetzt werden. Anderenfalls tritt bei manchen Programmen das Problem auf, daß beim Speichern eine Fehlermeldung der Art "permission denied" generiert wird, die Datei aber anschließend leer ist.
    • Bei Dateien unterscheidet unser Server nicht zwischen "write-data" und "append-data". Diese beiden Berechtigungen müssen daher immer gemeinsam angegeben oder weggelassen werden.
    • "write-owner" bezieht sich nicht nur auf den Besitzer, sondern auch auf die Gruppe, d.h. ohne "write-owner"-Berechtigung kann kein chgrp ausgeführt werden.
    • Der Besitzer einer Datei bzw. eines Verzeichnisses hat immer die Berechtigungen "read-ACL", "write-ACL", "read-attrs" und "write-attrs", unabhängig von der ACL.
    • Um eine Datei löschen zu dürfen, ist es ausreichend, wenn für die Datei delete erlaubt ist oder delete-child für das übergeordnete Verzeichnis.
    • "read-attrs", "write-attrs", "read-named-attrs" und "write-named-attrs" beziehen sich auf Dateiattribute, auf die hier nicht näher eingegangen wird. Informationen über Dateiattribute finden sich in der NFSv4-Spezifikation: RFC3530
    • "synchronize" bezieht sich nur auf Dateizugriffe, die lokal auf dem Server passieren.
    • Ein chmod-Aufruf führt meistens dazu, daß alle Benutzer- und Gruppen-ACEs gelöscht werden, und spezielle ACEs generiert werden, die den Mode-Bits entsprechen. Laut Implementing NFSv4 in the Enterprise bleibt die ACL nur dann erhalten, wenn mit chmod lediglich die Bits "setuid", "setgid" oder "sticky" geändert werden (z.B. mit chmod u+s,g+s,+t). Die Praxis zeigt jedoch, daß die ACL auch in anderen Fällen erhalten bleibt: Wenn beispielsweise auf eine Datei mit der ACL s:(OWNER@): a rwpDaAcCos ein chmod 600 angewendet wird, bleibt das D-Bit erhalten. Ein chmod 640 löscht jedoch das D-Bit und hängt ACEs für GROUP@ und EVERYONE@ an.
    • Standardmäßig wird an der Uni Augsburg die ksh als Login-Shell verwendet, und die umask wird (in ~/.kshrc) auf 022 gesetzt. Bei diesem umask-Wert werden Vererbungs-ACEs in manchen Fällen nicht an Dateien vererbt (für Spezialisten: wenn beim Anlegen der Datei fopen() mit dem Flag O_EXCL aufgerufen wird). Bei einem umask-Wert von 077 tritt dieses Problem nicht auf. Laut Implementing NFSv4 in the Enterprise sollte die umask überhaupt keinen Einfluß auf die Vererbung von ACLs haben.
    • Änderungen an Vererbungs-ACEs wirken sich nur auf neu angelegte Dateien und Verzeichnisse aus, d.h. bestehende ACLs bleiben unverändert.

Für den Umgang mit NFSv4-ACLs gibt es unter AIX und Linux jeweils drei Programme:

AIX Linux Beschreibung
aclget nfs4_getfacl ACL ausgeben
aclput nfs4_setfacl ACL setzen
acledit nfs4_editfacl ACL mit $EDITOR bearbeiten

Diese Programme befinden sich bei AIX in bos.rte.security und bei Ubuntu- bzw. Debian-Linux im Paket nfs4-acl-tools.

Beispiele

  • Auf ein Verzeichnis soll ausschließlich die Gruppe exp7-h Zugreifen dürfen, diese aber mit allen Zugriffsrechten ("Vollzugriff"). Das gleiche soll für alle Unterverzeichnisse und Dateien darin gelten:

AIX:

g:exp7-h:       a       rwpRWxDaAdcCos  fidi

Linux:

A:fdg:exp7-h@uni-augsburg.de:rwaDdxtTnNcCoy

Die Flags fidi (AIX) bzw. fd (Linux) bewirken, daß der ACE sowohl an Dateien als auch an Verzeichnisse vererbt wird.

  • Neu angelegte Dateien im Verzeichnis aus dem vorigen Beispiel sollen nicht ausführbar sein:

AIX:

g:exp7-h:       a       rwpRWxDaAdcCos  di
g:exp7-h:       a       rwpRWDaAdcCos   fioi

Linux:

A:dg:exp7-h@uni-augsburg.de:rwaDdxtTnNcCoy
A:fig:exp7-h@uni-augsburg.de:rwaDdtTnNcCoy

Hierfür sind getrennte ACEs für Vererbung an Dateien bzw. Verzeichnisse notwendig. Das Flag oi (AIX) bzw. i (Linux) im zweiten ACE bewirkt, daß diese Berechtigungen nicht für das Verzeichnis selbst gelten.

  • Auf das Verzeichnis im vorigen Beispiel soll zusätzlich die Gruppe exp7-m Lesezugriff erhalten. Das gleiche soll auch für neu angelegte Dateien und Verzeichnisse gelten:

AIX:

g:exp7-h:       a       rwpRWxDaAdcCos  di
g:exp7-h:       a       rwpRWDaAdcCos   fioi
g:exp7-m:       a       rx      di
g:exp7-m:       a       r       fioi

Linux:

A:dg:exp7-h@uni-augsburg.de:rwaDdxtTnNcCoy
A:fig:exp7-h@uni-augsburg.de:rwaDdtTnNcCoy
A:dg:exp7-m@uni-augsburg.de:rx
A:fig:exp7-m@uni-augsburg.de:r

Für die Gruppe exp7-m müssen zwei zusätzliche ACEs angehängt werden. Diese sind bis auf die Gruppe und die Berechtigungen identisch zu den ACEs für exp7-h.

  • Mit folgendem Kommando läßt sich die ACL einer Datei oder eines Verzeichnisses kopieren (von orig nach kopie):

AIX:

aclget orig | aclput kopie

Linux:

nfs4_getfacl orig | nfs4_setfacl -S - kopie

Quellen

Bemerkung zu den NFSv4 ACLs beim Zugriff über NFSv4 bzw. CIFS

  • Beim NFSv4 Export können die ACLs einfach durchgereicht werden. Ein Mapping auf andere Zugriffsmodelle findet statt, wenn Anwendungen andere Zugriffsmodelle erwarten. Typischerweise könnten dies POSIX mode bits sein.
  • Beim CIFS Export werden die ACLs (durch den Samba-Server) auf CIFS ACLs gemapped.

Im Prinzip sind NFSv4 ACLs ebenso konstruiert, dass sie ein mapping auf POSIX mode bits und auf CIFS ACLs bestmöglich unterstützen. Leider gibt es in der Praxis gelegentlich Probleme, da die Mappings nicht immer verlustfrei und/oder eindeutig erfolgen.