Linux/Zugriffskontrollliste: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
(55 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
== | '''Zugriffskontrollliste''' - ACL (Access Control List) | ||
[[ | |||
== Beschreibung == | |||
; Erweiterung der UNIX-Zugriffssteuerung | |||
Bei Access Control Lists lassen sich Zugriffsrechte spezifisch für einzelne Benutzer zuteilen oder verbieten | |||
* Als erstes Unix unterstützte HP-UX dieses Modell der erweiterten Zugriffssteuerung | |||
* Mittlerweile bieten auch Linux, FreeBSD (TrustedBSD) und Solaris (TrustedSolaris) native Unterstützung für ACLs | |||
* Unter Linux unterstützen dabei die Dateisysteme ext2, ext3, JFS, XFS und ReiserFS ACLs vollständig | |||
* Mit der KDE-Version 3.5 steht auch der Dateimanager Konqueror mit nativer ACL-Unterstützung zur Verfügung | |||
* Für den GNOME-Desktop beherrscht der Dateimanager Nautilus seit Version 2.16 nativ ACLs | |||
* ACLs werden in Linux statisch vererbt, d. h. die Berechtigungen pflanzen sich in neu angelegte Unterverzeichnisse und Dateien je nach Bedarf fort | |||
* Wird die ACL eines übergeordneten Verzeichnisses geändert, hat dies keinen Einfluss auf die darunterliegende Struktur | |||
=== Vorteile von ACLs === | |||
; Traditionell sind für jedes Dateiobjekt unter Linux drei Berechtigungsgruppen definiert | |||
* Diese Gruppen enthalten die Berechtigungen zum Lesen (<tt>r</tt>), Schreiben (<tt>w</tt>) und Ausführen (<tt>x</tt>) für den Eigentümer der Datei, die Gruppe und andere Benutzer | |||
* Zusätzlich können noch die bit für ''set user id'', ''set group id'' und das ''sticky''-Bit gesetzt werden | |||
* Dieses schlanke Konzept ist für die meisten in der Praxis auftretenden Fälle völlig ausreichend | |||
* Für komplexere Szenarien oder erweiterte Anwendungen mussten Systemadministratoren früher eine Reihe von Tricks anwenden, um die Einschränkungen des traditionellen Berechtigungskonzepts zu umgehen | |||
* ACLs können als Erweiterung des traditionellen Berechtigungskonzepts verwendet werden | |||
* Sie ermöglichen es, einzelnen Benutzern oder Gruppen, bei denen es sich nicht um den ursprünglichen Eigentümer oder die ursprüngliche Eigentümergruppe handelt, Berechtigungen zuzuweisen | |||
* ACLs sind eine Funktion des Linux-Kernels und werden derzeit von ReiserFS, Ext2, Ext3, JFS und XFS unterstützt | |||
* Mithilfe von ACLs können komplexe Szenarien umgesetzt werden, ohne dass auf Anwendungsebene komplexe Berechtigungsmodelle implementiert werden müssen | |||
* Die Vorzüge von ACLs zeigen sich, wenn Sie einen Windows-Server durch einen Linux-Server ersetzen möchten | |||
* Einige der angeschlossenen Arbeitsstationen können auch nach der Migration weiter unter Windows betrieben werden | |||
* Das Linux-System stellt den Windows-Clients Datei- und Druckdienste über Samba zur Verfügung | |||
* Da Samba ACLs unterstützt, können Benutzerberechtigungen sowohl auf dem Linux-Server als auch über eine grafische Benutzeroberfläche unter Windows (nur Windows NT und höher) konfiguriert werden | |||
* Über '''winbindd''', einem Teil der Samba-Suite, ist es sogar möglich, Benutzern, die nur in der Windows-Domäne existieren und über kein Konto auf dem Linux-Server verfügen, Berechtigungen zu gewähren | |||
=== Definitionen === | |||
{| class="wikitable sortable" | |||
|- | |||
| | '''Benutzerklasse''' | |||
| | Das traditionelle POSIX-Berechtigungskonzept verwendet drei ''Klassen'' von Benutzern für das Zuweisen von Berechtigungen im Dateisystem: den Eigentümer (owner), die Eigentümergruppe (owning group) und andere Benutzer (other) | |||
* Pro Benutzerklasse können jeweils die drei Berechtigungsbit zum Lesen (<tt>r</tt>), Schreiben (<tt>w</tt>) und Ausführen (<tt>x</tt>) gesetzt werden | |||
|- | |||
| | '''Zugriffs-ACL''' | |||
| | Die Zugriffsberechtigungen für Benutzer und Gruppen auf beliebige Dateisystemobjekte (Dateien und Verzeichnisse) werden über Access ACLs (Zugriffs-ACLs) festgelegt | |||
|- | |||
| | '''Standard-ACL''' | |||
| | Standard-ACLs können nur auf Verzeichnisse angewandt werden | |||
* Diese legen fest, welche Berechtigungen ein Dateisystemobjekt übernimmt, wenn das Objekt von seinem übergeordneten Verzeichnis erstellt wird | |||
|- | |||
| | '''ACL-Eintrag''' | |||
| | Jede ACL besteht aus mehreren ACL-Einträgen | |||
* Ein ACL-Eintrag enthält einen Typ, einen Bezeichner für den Benutzer oder die Gruppe, auf den bzw. die sich der Eintrag bezieht, und Berechtigungen | |||
* Für einige Eintragstypen ist der Bezeichner für die Gruppe oder die Benutzer nicht definiert | |||
|- | |||
|} | |||
== Installation == | |||
sudo apt install acl | |||
== Konfiguration == | |||
=== Dateien === | |||
; /etc/fstab | |||
== Anwendung == | |||
; Arbeiten mit ACLs | |||
Die Tabelle „Typen von ACL-Einträgen“ fasst die sechs möglichen Typen von ACL-Einträgen zusammen und beschreibt die für einen Benutzer oder eine Gruppe von Benutzern verfügbaren Berechtigungen | |||
* Der Eintrag ''owner'' definiert die Berechtigungen des Benutzers, der Eigentümer der Datei oder des Verzeichnisses ist | |||
* Der Eintrag ''owning group'' definiert die Berechtigungen der Gruppe, die Eigentümer der Datei ist | |||
* Der Superuser kann den Eigentümer (owner) oder die Eigentümergruppe (owning group) mit '''chown''' oder '''chgrp''' ändern, in welchem Fall die Einträge „owner“ und „owning group“ sich auf den neuen Eigentümer bzw. die neue Eigentümergruppe beziehen | |||
* Die Einträge des Typs ''named user'' definieren die Berechtigungen des Benutzers, der im Bezeichnerfeld des Eintrags angegeben ist | |||
* Die Einträge des Typs ''named group'' definieren die Berechtigungen der im Bezeichnerfeld des Eintrags angegebenen Gruppe | |||
* Nur die Einträge des Typs „named user“ und „named group“ verfügen über ein Bezeichnerfeld, das nicht leer ist | |||
* Der Eintrag ''other'' definiert die Berechtigungen aller anderen Benutzer | |||
* Der Eintrag ''mask'' schränkt die durch die Einträge „named user“, „named group“ und „owning group“ gewährten Berechtigungen ein, indem durch ihn festgelegt werden kann, welche der Berechtigungen in diesen Einträgen wirksam und welche maskiert sind | |||
* Sind Berechtigungen sowohl in einem der oben genannten Einträge als auch in der Maske vorhanden, werden sie wirksam | |||
* Berechtigungen, die nur in der Maske oder nur im eigentlichen Eintrag vorhanden sind, sind nicht wirksam, d. h., die Berechtigungen werden nicht gewährt | |||
* Die in den Einträgen „owner“ und „owning group“ gewährten Berechtigungen sind immer wirksam | |||
* Dieser Mechanismus wird mit dem Beispiel in Tabelle „Maskierung von Zugriffsberechtigungen“ verdeutlicht | |||
* Es gibt zwei grundlegende Klassen von ACLs: Eine ''minimale'' ACL enthält nur die Einträge für die Typen „owner“, „owning group“ und „other“, die den traditionellen Berechtigungsbit für Dateien und Verzeichnisse entsprechen | |||
* Eine ''erweiterte'' ACL geht über dieses Konzept hinaus | |||
* Sie muss einen Eintrag des Typs „mask“ enthalten und kann mehrere Einträge des Typs „named user“ und „named group“ haben | |||
'''Typen von ACL-Einträgen''' | |||
{| class="wikitable sortable" | |||
|- | |||
| | '''Typ''' | |||
| | '''Textformat''' | |||
|- | |||
| | owner | |||
| | <tt>user::rwx</tt> | |||
|- | |||
| | named user | |||
| | <tt>user:name:rwx</tt> | |||
|- | |||
| | owning group | |||
| | <tt>group::rwx</tt> | |||
|- | |||
| | named group | |||
| | <tt>group:name:rwx</tt> | |||
|- | |||
| | mask | |||
| | <tt>mask::rwx</tt> | |||
|- | |||
| | other | |||
| | <tt>other::rwx</tt> | |||
|- | |||
|} | |||
'''Maskierung von Zugriffsberechtigungen''' | |||
{| class="wikitable sortable" | |||
|- | |||
| | '''Eintragstyp''' | |||
| | '''Textformat''' | |||
| | '''Berechtigungen''' | |||
|- | |||
| | named user | |||
| | <tt>user:geeko:r-x</tt> | |||
| | <tt>r-x</tt> | |||
|- | |||
| | mask | |||
| | <tt>mask::rw-</tt> | |||
| | <tt>rw-</tt> | |||
|- | |||
| | | |||
| | wirksame Berechtigungen: | |||
| | <tt>r--</tt> | |||
|- | |||
|} | |||
=== ACL-Einträge und Berechtigungsbit === | |||
Die Abbildung „Minimale ACL: ACL-Einträge vs. Berechtigungsbit“ und Abbildung „Erweiterte ACL: ACL-Einträge vs. Berechtigungsbit“ zeigen eine minimale und eine erweiterte ACL | |||
* Die Abbildungen sind in drei Blöcke gegliedert | |||
* Der linke Block zeigt die Typspezifikationen der ACL-Einträge, der mittlere Block zeigt ein Beispiel einer ACL und der rechte Block zeigt die entsprechenden Berechtigungsbit gemäß dem herkömmlichen Berechtigungskonzept, wie sie beispielsweise auch '''ls''' <tt>-l</tt> anzeigt | |||
* In beiden Fällen werden die Berechtigungen ''owner class'' dem ACL-Eintrag „owner“ zugeordnet | |||
* ''Other class''-Berechtigungen werden dem entsprechenden ACL-Eintrag zugeordnet | |||
* Die Zuordnung der Berechtigungen des Typs ''group class'' ist in den beiden Fällen jedoch unterschiedlich | |||
'''Minimale ACL: ACL-Einträge vs. Berechtigungsbit''' | |||
[[Image:Grafik3.png]] | |||
* Im Fall einer minimalen ACL – ohne „mask“ – werden die „group class“-Berechtigungen dem ACL-Eintrag „owning group“ zugeordnet | |||
* Im Fall einer erweiterten ACL – mit „mask“ – werden die „group class“-Berechtigungen dem „mask“-Eintrag zugeordnet | |||
* Dies ist in Abbildung „Erweiterte ACL: ACL-Einträge vs. Berechtigungsbit“ dargestellt | |||
'''Erweiterte ACL: ACL-Einträge vs. Berechtigungsbit''' | |||
[[Image:Grafik4.png]] | |||
* Durch diese Art der Zuordnung ist die reibungslose Interaktion von Anwendungen mit und ohne ACL-Unterstützung gewährleistet | |||
* Die Zugriffsberechtigungen, die mittels der Berechtigungsbit festgelegt wurden, sind die Obergrenze für alle anderen „Feineinstellungen“, die per ACL vorgenommen werden | |||
* Werden Berechtigungsbit geändert, spiegelt sich dies in der ACL wider und umgekehrt | |||
=== Verzeichnis mit einer Zugriffs-ACL === | |||
Mit '''getfacl''' und '''setfacl''' in der Befehlszeile können Sie auf ACLs zugreifen | |||
* Die Verwendung dieser Befehle wird im folgenden Beispiel erläutert: | |||
* Bevor Sie das Verzeichnis erstellen, können Sie mit dem Befehl '''umask''' festlegen, welche Zugriffsberechtigungen gleich beim Erstellen von Dateiobjekten maskiert werden sollen | |||
* Der Befehl '''umask''' <tt>027</tt> legt die Standardberechtigungen fest, wobei er dem Eigentümer sämtliche Berechtigungen (<tt>0</tt>) gewährt, der Gruppe den Schreibzugriff (<tt>2</tt>) verweigert und allen anderen Benutzern überhaupt keine Berechtigungen erteilt (<tt>7</tt>) | |||
* Die entsprechenden Berechtigungsbit werden von '''umask''' maskiert oder deaktiviert | |||
* Weitere Informationen hierzu finden Sie auf der Manualpage '''umask''' | |||
* '''mkdir mydir''' erstellt das Verzeichnis <tt>mydir</tt> mit den durch '''umask''' festgelegten Standardberechtigungen | |||
* Mit dem Befehl '''ls '''<tt>-dl mydir</tt> können Sie prüfen, ob alle Berechtigungen ordnungsgemäß zugewiesen wurden | |||
* Die Ausgabe für dieses Beispiel sieht wie folgt aus: | |||
drwxr-x--- ... tux project3 ... mydir | |||
Mit dem Befehl '''getfacl '''<tt>mydir</tt> prüfen Sie den anfänglichen Status der ACL | |||
* Es werden ähnliche Informationen wie im folgenden Beispiel zurückgegeben: | |||
# file: mydir | |||
# owner: tux | |||
# group: project3 | |||
user::rwx | |||
group::r-x | |||
other::--- | |||
Die ersten drei Zeilen der Ausgabe nennen Namen, Eigentümer und Eigentümergruppe des Verzeichnisses | |||
Die drei nächsten Zeilen enthalten die drei ACL-Einträge „owner“, „owning group“ und „other“ | |||
* Insgesamt liefert Ihnen der Befehl '''getfacl''' im Fall dieser minimalen ACL keine Informationen, die Sie mit '''ls''' nicht auch erhalten hätten | |||
Ändern Sie die ACL so, dass Sie dem zusätzlichen Benutzer <tt>geeko</tt> und der zusätzlichen Gruppe <tt>mascots</tt> Lese-, Schreib- und Ausführberechtigungen gewähren, indem Sie folgenden Befehl eingeben: | |||
setfacl -m user:geeko:rwx,group:mascots:rwx mydir | |||
Mit der Option <tt>-m</tt> kann per '''setfacl''' die vorhandene ACL geändert werden | |||
* Das nachfolgende Argument gibt an, welche ACL-Einträge geändert werden (mehrere Einträge werden durch Kommas voneinander getrennt) | |||
Im letzten Teil geben Sie den Namen des Verzeichnisses an, für das diese Änderungen gelten sollen | |||
* Mit dem Befehl '''getfacl''' können Sie sich die resultierende ACL ansehen | |||
# file: mydir | |||
# owner: tux | |||
# group: project3 | |||
user::rwx | |||
user:geeko:rwx | |||
group::r-x | |||
group:mascots:rwx | |||
mask::rwx | |||
other::--- | |||
Zusätzlich zu den von Ihnen erstellten Einträgen für den Benutzer <tt>geeko</tt> und die Gruppe <tt>mascots</tt> wurde ein „mask“-Eintrag generiert | |||
Der mask-Eintrag wird automatisch gesetzt, sodass alle Berechtigungen wirksam sind | |||
* Außerdem passt '''setfacl''' vorhandene mask-Einträge automatisch an die geänderten Einstellungen an, es sei denn, Sie deaktivieren diese Funktion mit <tt>-n</tt>. „mask“ legt die maximal wirksamen Zugriffsberechtigungen für alle Einträge innerhalb der „group class“ fest | |||
Dazu gehören „named user“, „named group“ und „owning group“ | |||
* Die Berechtigungsbit des Typs „group class“, die mit '''ls''' <tt>-dl mydir</tt> ausgegeben werden, entsprechen jetzt dem <tt>mask</tt>-Eintrag | |||
drwxrwx---+ ... tux project3 ... mydir | |||
Die erste Spalte der Ausgabe enthält ein zusätzliches <tt>+</tt>, um darauf hinzuweisen, dass für dieses Objekt eine ''erweiterte'' ACL vorhanden ist | |||
Gemäß der Ausgabe des Befehls '''ls''' beinhalten die Berechtigungen für den mask-Eintrag auch Schreibzugriff | |||
* Solche Berechtigungsbit würden normalerweise bedeuten, dass die „owning group“ (hier <tt>project3</tt>) ebenfalls Schreibzugriff auf das Verzeichnis <tt>mydir</tt> hätte | |||
Allerdings sind die wirklich wirksamen Zugriffsberechtigungen für die „owning group“ als die Schnittmenge aus den für „owning group“ und den für „mask“ gesetzten Berechtigungen definiert, in unserem Beispiel also <tt>r-x</tt> | |||
Was die wirksamen Berechtigungen der „owning group“ in diesem Beispiel betrifft, hat sich also nach dem Hinzufügen der ACL-Einträge nichts geändert | |||
Bearbeiten Sie den mask-Eintrag mit '''setfacl''' oder '''chmod''' | |||
* Geben Sie beispielsweise '''chmod '''<tt>g-w mydir</tt> ein | |||
'''ls '''<tt>-dl mydir</tt> gibt dann Folgendes aus: | |||
drwxr-x---+ ... tux project3 ... mydir | |||
'''getfacl '''<tt>mydir</tt> erzeugt folgende Ausgabe: | |||
# file: mydir | |||
# owner: tux | |||
# group: project3 | |||
user::rwx | |||
user:geeko:rwx # effective: r-x | |||
group::r-x | |||
group:mascots:rwx # effective: r-x | |||
mask::r-x | |||
other::--- | |||
Nachdem Sie mit dem Befehl '''chmod''' den Schreibzugriff über die „group class“-Bit deaktiviert haben, liefert Ihnen bereits die Ausgabe des Befehls '''ls''' den Hinweis darauf, dass die mask-bit entsprechend angepasst wurden: | |||
* Die Schreibberechtigung ist wieder auf den Eigentümer von <tt>mydir</tt> beschränkt | |||
* Dies wird durch die Ausgabe des Befehls '''getfacl''' bestätigt | |||
* Dieser Befehl fügt allen Einträgen Kommentare hinzu, deren tatsächlich wirksame Berechtigungsbit nicht mit den ursprünglich gesetzten übereinstimmen, weil sie vom mask-Eintrag herausgefiltert werden | |||
* Die ursprünglichen Berechtigungen können jederzeit mit dem Befehl '''chmod '''<tt>g+w mydir</tt> wiederhergestellt werden | |||
=== Verzeichnis mit einer Standard-ACL === | |||
Verzeichnisse können über eine Standard-ACL verfügen | |||
* Dabei handelt es sich um einen speziellen Typ von ACL, der festlegt, welche Zugriffsberechtigungen neue Unterobjekte dieses Verzeichnisses bei ihrer Erstellung erben | |||
* Eine Standard-ACL wirkt sich sowohl auf Unterverzeichnisse als auch auf Dateien aus | |||
==== Auswirkungen einer Standard-ACL ==== | |||
* Die Zugriffsberechtigungen in der Standard-ACL eines Verzeichnisses werden an Dateien und Unterverzeichnisse unterschiedlich vererbt:* Ein Unterverzeichnis erbt die Standard-ACL des übergeordneten Verzeichnisses sowohl als seine eigene Standard-ACL als auch als Zugriffs-ACL | |||
* Eine Datei erbt die Standard-ACL als ihre eigene Zugriffs-ACL | |||
* Alle Systemaufrufe, die Dateisystemobjekte anlegen, verwenden einen <tt>'''mode'''</tt>-Parameter, der die Zugriffsberechtigungen für das neu erstellte Dateisystemobjekt definiert | |||
* Hat das übergeordnete Verzeichnis keine Standard-ACL, werden die mit <tt>'''umask'''</tt> definierten Berechtigungsbit mit dem <tt>'''mode'''</tt>-Parameter von den Berechtigungen abgezogen und das Ergebnis wird dem neuen Objekt zugewiesen | |||
* Existiert eine Standard-ACL für das übergeordnete Verzeichnis, entsprechen die dem neuen Objekt zugewiesenen Berechtigungsbit der Schnittmenge aus den Berechtigungen des <tt>'''mode'''</tt>-Parameters und den in der Standard-ACL festgelegten Berechtigungen | |||
* <tt>'''umask'''</tt> wird in diesem Fall nicht beachtet | |||
==== Standard-ACLs in der Praxis ==== | |||
* Die drei folgenden Beispiele führen Sie an die wichtigsten Operationen an Verzeichnissen und Standard-ACLs heran:# Fügen Sie dem vorhandenen Verzeichnis <tt>mydir</tt> eine Standard-ACL hinzu, indem Sie folgenden Befehl eingeben:<br/>setfacl -d -m group:mascots:r-x mydir<br/>Die Option <tt>-d</tt> des Befehls '''setfacl''' weist '''setfacl''' an, die folgenden Änderungen (Option <tt>-m</tt>) an der Standard-ACL vorzunehmen.<br/> | |||
Sehen Sie sich das Ergebnis dieses Befehls genauer an: | |||
$ getfacl mydir | |||
# file: mydir | |||
# owner: tux | |||
# group: project3 | |||
user::rwx | |||
user:geeko:rwx | |||
group::r-x | |||
group:mascots:rwx | |||
mask::rwx | |||
other::--- | |||
default:user::rwx | |||
default:group::r-x | |||
default:group:mascots:r-x | |||
default:mask::r-x | |||
default:other::--- | |||
'''getfacl''' gibt sowohl die Zugriffs-ACL als auch die Standard-ACL zurück | |||
* Die Standard-ACL setzt sich aus allen Zeilen zusammen, die mit <tt>default</tt> beginnen | |||
* Obwohl Sie den Befehl '''setfacl''' nur mit einem Eintrag für die Gruppe <tt>mascots</tt> für die Standard-ACL ausgeführt haben, hat '''setfacl''' automatisch alle anderen Einträge aus der Zugriffs-ACL kopiert, um so eine gültige Standard-ACL zu bilden | |||
* Standard-ACLs haben keine direkten Auswirkungen auf Zugriffsberechtigungen | |||
* Sie wirken sich nur beim Erstellen von Dateisystemobjekten aus | |||
* Diese neuen Objekte übernehmen Berechtigungen nur aus der Standard-ACL ihres übergeordneten Verzeichnisses | |||
Im nächsten Beispiel wird mit '''mkdir''' ein Unterverzeichnis in <tt>mydir</tt> angelegt, das die Standard-AC übernimmt | |||
$ mkdir mydir/mysubdir | |||
$ getfacl mydir/mysubdir | |||
# file: mydir/mysubdir | |||
# owner: tux | |||
# group: project3 | |||
user::rwx | |||
group::r-x | |||
group:mascots:r-x | |||
mask::r-x | |||
other::--- | |||
default:user::rwx | |||
default:group::r-x | |||
default:group:mascots:r-x | |||
default:mask::r-x | |||
default:other::--- | |||
Wie erwartet, hat das neu angelegte Unterverzeichnis <tt>mysubdir</tt> die Berechtigungen aus der Standard-ACL des übergeordneten Verzeichnisses geerbt | |||
* Die Zugriffs-ACL von <tt>mysubdir</tt> ist ein exaktes Abbild der Standard-ACL von <tt>mydir</tt> | |||
* Die Standard-ACL, die dieses Verzeichnis an ihre untergeordneten Objekte weitervererbt, ist ebenfalls dieselbe | |||
# Legen Sie mit '''touch''' eine Datei im Verzeichnis <tt>mydir</tt> an | |||
Beispiel: '''touch '''<tt>mydir/myfile</tt>. '''ls '''<tt>-l mydir/myfile</tt> gibt dann Folgendes zurück: | |||
-rw-r-----+ ... tux project3 ... mydir/myfile | |||
Die Ausgabe von '''getfacl '''<tt>mydir/myfile</tt> lautet wie folgt: | |||
# file: mydir/myfile | |||
# owner: tux | |||
# group: project3 | |||
user::rw- | |||
group::r-x # effective:r-- | |||
group:mascots:r-x # effective:r-- | |||
mask::r-- | |||
other::--- | |||
'''touch''' übergibt <tt>mode</tt> mit dem Wert <tt>0666</tt> | |||
* Dies bedeutet, dass neue Dateien mit Lese- und Schreibberechtigungen für alle Benutzerklassen angelegt werden, vorausgesetzt, '''umask''' oder die Standard-ACL enthalten keine weiteren Einschränkungen (siehe [../../../material/linux/aaa_projekte/skript/tmp/sec.acls.handle.html#sec.acls.handle.defacl.eff Abschnitt „Auswirkungen einer Standard-ACL“]). <br/>Am konkreten Beispiel heißt dies, dass alle Zugriffsberechtigungen, die nicht im <tt>mode</tt>-Wert enthalten sind, aus den entsprechenden ACL-Einträgen entfernt werden. <br/>Aus dem ACL-Eintrag der „group class“ wurden keine Berechtigungen entfernt, allerdings wurde der mask-Eintrag dahin gehend angepasst, dass Berechtigungsbit, die nicht mit <tt>mode</tt> gesetzt werden, maskiert werden. <br/>Auf diese Weise ist sichergestellt, dass Anwendungen, zum Beispiel Compiler, reibungslos mit ACLs interagieren können. <br/>Sie können Dateien mit beschränkten Zugriffsberechtigungen erstellen und diese anschließend als ausführbar markieren. <br/>Über den '''mask'''-Mechanismus ist gewährleistet, dass die richtigen Benutzer und Gruppen die Dateien wie gewünscht ausführen können | |||
=== ACL-Auswertungsalgorithmus === | |||
Bevor ein Prozess oder eine Anwendung Zugriff auf ein durch eine ACL geschütztes Dateisystemobjekt erhält, wird ein Auswertungsalgorithmus angewandt | |||
* Die ACL-Einträge werden grundsätzlich in der folgenden Reihenfolge untersucht: „owner“, „named user“, „owning group“ oder „named group“ und „other“ | |||
* Über den Eintrag, der am besten auf den Prozess passt, wird schließlich der Zugriff geregelt | |||
* Berechtigungen werden nicht akkumuliert | |||
* Komplizierter werden die Verhältnisse, wenn ein Prozess zu mehr als einer Gruppe gehört, also potenziell auch mehrere group-Einträge dazu passen können | |||
* Aus den passenden Einträgen mit den erforderlichen Berechtigungen wird per Zufallsprinzip ein Eintrag ausgesucht | |||
* Für das Endresultat „Zugriff gewährt“ ist es natürlich unerheblich, welcher dieser Einträge den Ausschlag gegeben hat | |||
* Ähnliches gilt, wenn keiner der passenden group-Einträge die erforderlichen Berechtigungen enthält | |||
* In diesem Fall löst ein per Zufallsprinzip ausgewählter Eintrag das Ergebnis „Zugriff verweigert“ aus | |||
=== ACL-Unterstützung in Anwendungen === | |||
Mit ACLs können sehr anspruchsvolle Berechtigungsszenarien umgesetzt werden, die den Anforderungen moderner Anwendungen gerecht werden | |||
* Das traditionelle Berechtigungskonzept und ACLs lassen sich geschickt miteinander kombinieren | |||
* Die grundlegenden Dateibefehle ('''cp''', '''mv''', '''ls''' usw.) unterstützen ACLs ebenso wie Samba und Konqueror | |||
* Viele Editoren und Dateimanager bieten jedoch keine ACL-Unterstützung | |||
* Beim Kopieren von Dateien mit Emacs gehen die ACLs der entsprechenden Dateien beispielsweise noch verloren | |||
* Wenn Dateien mit einer Zugriffs-ACL im Editor bearbeitet werden, hängt es vom Backup-Modus des verwendeten Editors ab, ob die Zugriffs-ACL nach Abschluss der Bearbeitung weiterhin vorliegt | |||
* Schreibt der Editor die Änderungen in die Originaldatei, bleibt die Zugriffs-ACL erhalten | |||
* Legt der Editor eine neue Datei an, die nach Abschluss der Änderungen in die alte umbenannt wird, gehen die ACLs möglicherweise verloren, es sei denn, der Editor unterstützt ACLs | |||
* Mit Ausnahme von Star Archiver gibt es derzeit keine Backup-Anwendungen, bei deren Verwendung die ACLs erhalten bleiben | |||
=== Vererbung von Gruppenrechten === | |||
Wie können Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden | |||
==== Problemstellung ==== | |||
Das Problem der Vererbung von GIDs und Gruppenrechten tritt z. B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen | |||
* Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das "chmod"-Kommando vornehmen müsste | |||
Offenbar ist das Thema weniger trivial, als man meinen möchte | |||
* Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen | |||
* Das stimmt so leider nicht - und so mancher beginnt dann mit \1 zu experimentieren | |||
* Was auch nicht hilft, weil das nur einmalige - wenn auch rekursive - Änderungen im betroffenen Zweig des Dateibaums herbeiführt | |||
* Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten | |||
Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen | |||
* Wir wollen hier aber eine native Lösung für beschreiben | |||
Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit | |||
==== Vorgehen ==== | |||
Wir nehmen zwei User eines Systems - "alpha" (uid 1001; dieser User wird der Entwicklunsgleiter) und "beta" (uid 1002) | |||
* Beide seine Mitglieder der Gruppe "users" (gid 100) | |||
* umask habe den Standardwert | |||
umask 022 | |||
; Was ist nun zu tun? | |||
'''Schritt 1: Anlegen einer gemeinsamen Usergruppe '''Als root: Anlegen einer neuen Gruppe "entwickler" (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z. B. mit Hilfe von Yast; ansonsten mit "groupadd" und "usermod -A" - siehe die man-Seiten) | |||
'''Schritt 2: Check, ob ACLs für das Filesystem aktiviert sind'''Als root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option "acl" gemounted wird | |||
* In der Datei "/etc/fstab" sollte sich dafür ein Eintrag der Form | |||
/dev/myFileSystem /myMountPoint ext4 acl,user_xattr 1 2 | |||
finden. "myFileSystem" steht hier für das betroffene Filesystem. "/myMountPoint" steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird | |||
* Entscheidend ist die Option "acl" | |||
'''Schritt 3: Anlegen des Verzeichnisses für die gemeinsame Entwicklungsarbeit'''Als root oder Entwicklungsleiter "alpha": Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll | |||
mkdir /myMountPoint/Entwicklung | |||
Danach Ändern der Gruppe und der Rechte | |||
chgrp entwicklung /myMountPoint/Entwicklung | |||
chmod 775 /myMountPoint/Entwicklung | |||
'''Schritt 4: Setzen des SetGID-Bit'''Als Entwicklungsleiter "alpha": | |||
chmod g+s /myMountPoint/Entwicklung | |||
Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses "/myMountPoint/Entwicklung" angelegt werden, die die Gruppenzugehörigkeit zur Gruppe "entwicklung" | |||
'''Schritt 5: Setzen der ACL-Maske'''Als Entwicklungsleiter "alpha": | |||
cd /myMountPoint4 | |||
setfacl -m m::rwx Entwicklung | |||
Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis "Entwicklung" | |||
'''Schritt 6: Setzen der Default-Rechte für künftige Dateien und Unterverzeichnisse'''Als Entwicklungsleiter "alpha": | |||
cd /myMountPoint | |||
setfacl -dm g:entwicklung:rwx Entwicklung | |||
'''Schritt 7: Prüfen der Rechte für neue Dateien und Unterverzeichnisse'''Als Gruppenmitglied "beta": | |||
cd /myMountPoint/Entwicklung | |||
touch test | |||
ls -l | |||
-rw-rw-r--+ 1 beta entwicklung 0 20. Jul 20:18 test | |||
mkdir testdir | |||
ls -l | |||
drwxrwsr-x+ 2 beta entwicklung 4096 20. Jul 21:20 testdir | |||
touch testdir/test2 | |||
ls -l testdir | |||
-rw-rw-r--+ 1 beta entwicklung 0 20. Jul 21:22 test2 | |||
=== Problembehebung === | |||
<noinclude> | |||
== Anhang == | |||
=== Siehe auch === | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}}} | |||
==== Dokumentation ==== | |||
===== Man-Pages ===== | |||
# [[getfacl]](1) | |||
# [[acl]](5) | |||
# [[setfacl]](1) | |||
===== Info-Pages ===== | |||
==== Links ==== | |||
===== Projekt ===== | |||
===== Weblinks ===== | |||
# https://wiki.ubuntuusers.de/ACL/ | |||
# http://wiki.ubuntuusers.de/chmod | |||
# http://wiki.ubuntuusers.de/ACL | |||
# http://acl.bestbits.at | |||
[[Kategorie:Linux/Zugriffsrechte]] | |||
</noinclude> |
Aktuelle Version vom 30. Oktober 2024, 10:21 Uhr
Zugriffskontrollliste - ACL (Access Control List)
Beschreibung
- Erweiterung der UNIX-Zugriffssteuerung
Bei Access Control Lists lassen sich Zugriffsrechte spezifisch für einzelne Benutzer zuteilen oder verbieten
- Als erstes Unix unterstützte HP-UX dieses Modell der erweiterten Zugriffssteuerung
- Mittlerweile bieten auch Linux, FreeBSD (TrustedBSD) und Solaris (TrustedSolaris) native Unterstützung für ACLs
- Unter Linux unterstützen dabei die Dateisysteme ext2, ext3, JFS, XFS und ReiserFS ACLs vollständig
- Mit der KDE-Version 3.5 steht auch der Dateimanager Konqueror mit nativer ACL-Unterstützung zur Verfügung
- Für den GNOME-Desktop beherrscht der Dateimanager Nautilus seit Version 2.16 nativ ACLs
- ACLs werden in Linux statisch vererbt, d. h. die Berechtigungen pflanzen sich in neu angelegte Unterverzeichnisse und Dateien je nach Bedarf fort
- Wird die ACL eines übergeordneten Verzeichnisses geändert, hat dies keinen Einfluss auf die darunterliegende Struktur
Vorteile von ACLs
- Traditionell sind für jedes Dateiobjekt unter Linux drei Berechtigungsgruppen definiert
- Diese Gruppen enthalten die Berechtigungen zum Lesen (r), Schreiben (w) und Ausführen (x) für den Eigentümer der Datei, die Gruppe und andere Benutzer
- Zusätzlich können noch die bit für set user id, set group id und das sticky-Bit gesetzt werden
- Dieses schlanke Konzept ist für die meisten in der Praxis auftretenden Fälle völlig ausreichend
- Für komplexere Szenarien oder erweiterte Anwendungen mussten Systemadministratoren früher eine Reihe von Tricks anwenden, um die Einschränkungen des traditionellen Berechtigungskonzepts zu umgehen
- ACLs können als Erweiterung des traditionellen Berechtigungskonzepts verwendet werden
- Sie ermöglichen es, einzelnen Benutzern oder Gruppen, bei denen es sich nicht um den ursprünglichen Eigentümer oder die ursprüngliche Eigentümergruppe handelt, Berechtigungen zuzuweisen
- ACLs sind eine Funktion des Linux-Kernels und werden derzeit von ReiserFS, Ext2, Ext3, JFS und XFS unterstützt
- Mithilfe von ACLs können komplexe Szenarien umgesetzt werden, ohne dass auf Anwendungsebene komplexe Berechtigungsmodelle implementiert werden müssen
- Die Vorzüge von ACLs zeigen sich, wenn Sie einen Windows-Server durch einen Linux-Server ersetzen möchten
- Einige der angeschlossenen Arbeitsstationen können auch nach der Migration weiter unter Windows betrieben werden
- Das Linux-System stellt den Windows-Clients Datei- und Druckdienste über Samba zur Verfügung
- Da Samba ACLs unterstützt, können Benutzerberechtigungen sowohl auf dem Linux-Server als auch über eine grafische Benutzeroberfläche unter Windows (nur Windows NT und höher) konfiguriert werden
- Über winbindd, einem Teil der Samba-Suite, ist es sogar möglich, Benutzern, die nur in der Windows-Domäne existieren und über kein Konto auf dem Linux-Server verfügen, Berechtigungen zu gewähren
Definitionen
Benutzerklasse | Das traditionelle POSIX-Berechtigungskonzept verwendet drei Klassen von Benutzern für das Zuweisen von Berechtigungen im Dateisystem: den Eigentümer (owner), die Eigentümergruppe (owning group) und andere Benutzer (other)
|
Zugriffs-ACL | Die Zugriffsberechtigungen für Benutzer und Gruppen auf beliebige Dateisystemobjekte (Dateien und Verzeichnisse) werden über Access ACLs (Zugriffs-ACLs) festgelegt |
Standard-ACL | Standard-ACLs können nur auf Verzeichnisse angewandt werden
|
ACL-Eintrag | Jede ACL besteht aus mehreren ACL-Einträgen
|
Installation
sudo apt install acl
Konfiguration
Dateien
- /etc/fstab
Anwendung
- Arbeiten mit ACLs
Die Tabelle „Typen von ACL-Einträgen“ fasst die sechs möglichen Typen von ACL-Einträgen zusammen und beschreibt die für einen Benutzer oder eine Gruppe von Benutzern verfügbaren Berechtigungen
- Der Eintrag owner definiert die Berechtigungen des Benutzers, der Eigentümer der Datei oder des Verzeichnisses ist
- Der Eintrag owning group definiert die Berechtigungen der Gruppe, die Eigentümer der Datei ist
- Der Superuser kann den Eigentümer (owner) oder die Eigentümergruppe (owning group) mit chown oder chgrp ändern, in welchem Fall die Einträge „owner“ und „owning group“ sich auf den neuen Eigentümer bzw. die neue Eigentümergruppe beziehen
- Die Einträge des Typs named user definieren die Berechtigungen des Benutzers, der im Bezeichnerfeld des Eintrags angegeben ist
- Die Einträge des Typs named group definieren die Berechtigungen der im Bezeichnerfeld des Eintrags angegebenen Gruppe
- Nur die Einträge des Typs „named user“ und „named group“ verfügen über ein Bezeichnerfeld, das nicht leer ist
- Der Eintrag other definiert die Berechtigungen aller anderen Benutzer
- Der Eintrag mask schränkt die durch die Einträge „named user“, „named group“ und „owning group“ gewährten Berechtigungen ein, indem durch ihn festgelegt werden kann, welche der Berechtigungen in diesen Einträgen wirksam und welche maskiert sind
- Sind Berechtigungen sowohl in einem der oben genannten Einträge als auch in der Maske vorhanden, werden sie wirksam
- Berechtigungen, die nur in der Maske oder nur im eigentlichen Eintrag vorhanden sind, sind nicht wirksam, d. h., die Berechtigungen werden nicht gewährt
- Die in den Einträgen „owner“ und „owning group“ gewährten Berechtigungen sind immer wirksam
- Dieser Mechanismus wird mit dem Beispiel in Tabelle „Maskierung von Zugriffsberechtigungen“ verdeutlicht
- Es gibt zwei grundlegende Klassen von ACLs: Eine minimale ACL enthält nur die Einträge für die Typen „owner“, „owning group“ und „other“, die den traditionellen Berechtigungsbit für Dateien und Verzeichnisse entsprechen
- Eine erweiterte ACL geht über dieses Konzept hinaus
- Sie muss einen Eintrag des Typs „mask“ enthalten und kann mehrere Einträge des Typs „named user“ und „named group“ haben
Typen von ACL-Einträgen
Typ | Textformat |
owner | user::rwx |
named user | user:name:rwx |
owning group | group::rwx |
named group | group:name:rwx |
mask | mask::rwx |
other | other::rwx |
Maskierung von Zugriffsberechtigungen
Eintragstyp | Textformat | Berechtigungen |
named user | user:geeko:r-x | r-x |
mask | mask::rw- | rw- |
wirksame Berechtigungen: | r-- |
ACL-Einträge und Berechtigungsbit
Die Abbildung „Minimale ACL: ACL-Einträge vs. Berechtigungsbit“ und Abbildung „Erweiterte ACL: ACL-Einträge vs. Berechtigungsbit“ zeigen eine minimale und eine erweiterte ACL
- Die Abbildungen sind in drei Blöcke gegliedert
- Der linke Block zeigt die Typspezifikationen der ACL-Einträge, der mittlere Block zeigt ein Beispiel einer ACL und der rechte Block zeigt die entsprechenden Berechtigungsbit gemäß dem herkömmlichen Berechtigungskonzept, wie sie beispielsweise auch ls -l anzeigt
- In beiden Fällen werden die Berechtigungen owner class dem ACL-Eintrag „owner“ zugeordnet
- Other class-Berechtigungen werden dem entsprechenden ACL-Eintrag zugeordnet
- Die Zuordnung der Berechtigungen des Typs group class ist in den beiden Fällen jedoch unterschiedlich
Minimale ACL: ACL-Einträge vs. Berechtigungsbit
- Im Fall einer minimalen ACL – ohne „mask“ – werden die „group class“-Berechtigungen dem ACL-Eintrag „owning group“ zugeordnet
- Im Fall einer erweiterten ACL – mit „mask“ – werden die „group class“-Berechtigungen dem „mask“-Eintrag zugeordnet
- Dies ist in Abbildung „Erweiterte ACL: ACL-Einträge vs. Berechtigungsbit“ dargestellt
Erweiterte ACL: ACL-Einträge vs. Berechtigungsbit
- Durch diese Art der Zuordnung ist die reibungslose Interaktion von Anwendungen mit und ohne ACL-Unterstützung gewährleistet
- Die Zugriffsberechtigungen, die mittels der Berechtigungsbit festgelegt wurden, sind die Obergrenze für alle anderen „Feineinstellungen“, die per ACL vorgenommen werden
- Werden Berechtigungsbit geändert, spiegelt sich dies in der ACL wider und umgekehrt
Verzeichnis mit einer Zugriffs-ACL
Mit getfacl und setfacl in der Befehlszeile können Sie auf ACLs zugreifen
- Die Verwendung dieser Befehle wird im folgenden Beispiel erläutert:
- Bevor Sie das Verzeichnis erstellen, können Sie mit dem Befehl umask festlegen, welche Zugriffsberechtigungen gleich beim Erstellen von Dateiobjekten maskiert werden sollen
- Der Befehl umask 027 legt die Standardberechtigungen fest, wobei er dem Eigentümer sämtliche Berechtigungen (0) gewährt, der Gruppe den Schreibzugriff (2) verweigert und allen anderen Benutzern überhaupt keine Berechtigungen erteilt (7)
- Die entsprechenden Berechtigungsbit werden von umask maskiert oder deaktiviert
- Weitere Informationen hierzu finden Sie auf der Manualpage umask
- mkdir mydir erstellt das Verzeichnis mydir mit den durch umask festgelegten Standardberechtigungen
- Mit dem Befehl ls -dl mydir können Sie prüfen, ob alle Berechtigungen ordnungsgemäß zugewiesen wurden
- Die Ausgabe für dieses Beispiel sieht wie folgt aus:
drwxr-x--- ... tux project3 ... mydir
Mit dem Befehl getfacl mydir prüfen Sie den anfänglichen Status der ACL
- Es werden ähnliche Informationen wie im folgenden Beispiel zurückgegeben:
# file: mydir # owner: tux # group: project3 user::rwx group::r-x other::---
Die ersten drei Zeilen der Ausgabe nennen Namen, Eigentümer und Eigentümergruppe des Verzeichnisses
Die drei nächsten Zeilen enthalten die drei ACL-Einträge „owner“, „owning group“ und „other“
- Insgesamt liefert Ihnen der Befehl getfacl im Fall dieser minimalen ACL keine Informationen, die Sie mit ls nicht auch erhalten hätten
Ändern Sie die ACL so, dass Sie dem zusätzlichen Benutzer geeko und der zusätzlichen Gruppe mascots Lese-, Schreib- und Ausführberechtigungen gewähren, indem Sie folgenden Befehl eingeben:
setfacl -m user:geeko:rwx,group:mascots:rwx mydir
Mit der Option -m kann per setfacl die vorhandene ACL geändert werden
- Das nachfolgende Argument gibt an, welche ACL-Einträge geändert werden (mehrere Einträge werden durch Kommas voneinander getrennt)
Im letzten Teil geben Sie den Namen des Verzeichnisses an, für das diese Änderungen gelten sollen
- Mit dem Befehl getfacl können Sie sich die resultierende ACL ansehen
# file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx group::r-x group:mascots:rwx mask::rwx other::---
Zusätzlich zu den von Ihnen erstellten Einträgen für den Benutzer geeko und die Gruppe mascots wurde ein „mask“-Eintrag generiert
Der mask-Eintrag wird automatisch gesetzt, sodass alle Berechtigungen wirksam sind
- Außerdem passt setfacl vorhandene mask-Einträge automatisch an die geänderten Einstellungen an, es sei denn, Sie deaktivieren diese Funktion mit -n. „mask“ legt die maximal wirksamen Zugriffsberechtigungen für alle Einträge innerhalb der „group class“ fest
Dazu gehören „named user“, „named group“ und „owning group“
- Die Berechtigungsbit des Typs „group class“, die mit ls -dl mydir ausgegeben werden, entsprechen jetzt dem mask-Eintrag
drwxrwx---+ ... tux project3 ... mydir
Die erste Spalte der Ausgabe enthält ein zusätzliches +, um darauf hinzuweisen, dass für dieses Objekt eine erweiterte ACL vorhanden ist
Gemäß der Ausgabe des Befehls ls beinhalten die Berechtigungen für den mask-Eintrag auch Schreibzugriff
- Solche Berechtigungsbit würden normalerweise bedeuten, dass die „owning group“ (hier project3) ebenfalls Schreibzugriff auf das Verzeichnis mydir hätte
Allerdings sind die wirklich wirksamen Zugriffsberechtigungen für die „owning group“ als die Schnittmenge aus den für „owning group“ und den für „mask“ gesetzten Berechtigungen definiert, in unserem Beispiel also r-x
Was die wirksamen Berechtigungen der „owning group“ in diesem Beispiel betrifft, hat sich also nach dem Hinzufügen der ACL-Einträge nichts geändert
Bearbeiten Sie den mask-Eintrag mit setfacl oder chmod
- Geben Sie beispielsweise chmod g-w mydir ein
ls -dl mydir gibt dann Folgendes aus:
drwxr-x---+ ... tux project3 ... mydir
getfacl mydir erzeugt folgende Ausgabe:
# file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx # effective: r-x group::r-x group:mascots:rwx # effective: r-x mask::r-x other::---
Nachdem Sie mit dem Befehl chmod den Schreibzugriff über die „group class“-Bit deaktiviert haben, liefert Ihnen bereits die Ausgabe des Befehls ls den Hinweis darauf, dass die mask-bit entsprechend angepasst wurden:
- Die Schreibberechtigung ist wieder auf den Eigentümer von mydir beschränkt
- Dies wird durch die Ausgabe des Befehls getfacl bestätigt
- Dieser Befehl fügt allen Einträgen Kommentare hinzu, deren tatsächlich wirksame Berechtigungsbit nicht mit den ursprünglich gesetzten übereinstimmen, weil sie vom mask-Eintrag herausgefiltert werden
- Die ursprünglichen Berechtigungen können jederzeit mit dem Befehl chmod g+w mydir wiederhergestellt werden
Verzeichnis mit einer Standard-ACL
Verzeichnisse können über eine Standard-ACL verfügen
- Dabei handelt es sich um einen speziellen Typ von ACL, der festlegt, welche Zugriffsberechtigungen neue Unterobjekte dieses Verzeichnisses bei ihrer Erstellung erben
- Eine Standard-ACL wirkt sich sowohl auf Unterverzeichnisse als auch auf Dateien aus
Auswirkungen einer Standard-ACL
- Die Zugriffsberechtigungen in der Standard-ACL eines Verzeichnisses werden an Dateien und Unterverzeichnisse unterschiedlich vererbt:* Ein Unterverzeichnis erbt die Standard-ACL des übergeordneten Verzeichnisses sowohl als seine eigene Standard-ACL als auch als Zugriffs-ACL
- Eine Datei erbt die Standard-ACL als ihre eigene Zugriffs-ACL
- Alle Systemaufrufe, die Dateisystemobjekte anlegen, verwenden einen mode-Parameter, der die Zugriffsberechtigungen für das neu erstellte Dateisystemobjekt definiert
- Hat das übergeordnete Verzeichnis keine Standard-ACL, werden die mit umask definierten Berechtigungsbit mit dem mode-Parameter von den Berechtigungen abgezogen und das Ergebnis wird dem neuen Objekt zugewiesen
- Existiert eine Standard-ACL für das übergeordnete Verzeichnis, entsprechen die dem neuen Objekt zugewiesenen Berechtigungsbit der Schnittmenge aus den Berechtigungen des mode-Parameters und den in der Standard-ACL festgelegten Berechtigungen
- umask wird in diesem Fall nicht beachtet
Standard-ACLs in der Praxis
- Die drei folgenden Beispiele führen Sie an die wichtigsten Operationen an Verzeichnissen und Standard-ACLs heran:# Fügen Sie dem vorhandenen Verzeichnis mydir eine Standard-ACL hinzu, indem Sie folgenden Befehl eingeben:
setfacl -d -m group:mascots:r-x mydir
Die Option -d des Befehls setfacl weist setfacl an, die folgenden Änderungen (Option -m) an der Standard-ACL vorzunehmen.
Sehen Sie sich das Ergebnis dieses Befehls genauer an:
$ getfacl mydir # file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx group::r-x group:mascots:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:mascots:r-x default:mask::r-x default:other::---
getfacl gibt sowohl die Zugriffs-ACL als auch die Standard-ACL zurück
- Die Standard-ACL setzt sich aus allen Zeilen zusammen, die mit default beginnen
- Obwohl Sie den Befehl setfacl nur mit einem Eintrag für die Gruppe mascots für die Standard-ACL ausgeführt haben, hat setfacl automatisch alle anderen Einträge aus der Zugriffs-ACL kopiert, um so eine gültige Standard-ACL zu bilden
- Standard-ACLs haben keine direkten Auswirkungen auf Zugriffsberechtigungen
- Sie wirken sich nur beim Erstellen von Dateisystemobjekten aus
- Diese neuen Objekte übernehmen Berechtigungen nur aus der Standard-ACL ihres übergeordneten Verzeichnisses
Im nächsten Beispiel wird mit mkdir ein Unterverzeichnis in mydir angelegt, das die Standard-AC übernimmt
$ mkdir mydir/mysubdir $ getfacl mydir/mysubdir # file: mydir/mysubdir # owner: tux # group: project3 user::rwx group::r-x group:mascots:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:mascots:r-x default:mask::r-x default:other::---
Wie erwartet, hat das neu angelegte Unterverzeichnis mysubdir die Berechtigungen aus der Standard-ACL des übergeordneten Verzeichnisses geerbt
- Die Zugriffs-ACL von mysubdir ist ein exaktes Abbild der Standard-ACL von mydir
- Die Standard-ACL, die dieses Verzeichnis an ihre untergeordneten Objekte weitervererbt, ist ebenfalls dieselbe
- Legen Sie mit touch eine Datei im Verzeichnis mydir an
Beispiel: touch mydir/myfile. ls -l mydir/myfile gibt dann Folgendes zurück:
-rw-r-----+ ... tux project3 ... mydir/myfile
Die Ausgabe von getfacl mydir/myfile lautet wie folgt:
# file: mydir/myfile # owner: tux # group: project3 user::rw- group::r-x # effective:r-- group:mascots:r-x # effective:r-- mask::r-- other::---
touch übergibt mode mit dem Wert 0666
- Dies bedeutet, dass neue Dateien mit Lese- und Schreibberechtigungen für alle Benutzerklassen angelegt werden, vorausgesetzt, umask oder die Standard-ACL enthalten keine weiteren Einschränkungen (siehe [../../../material/linux/aaa_projekte/skript/tmp/sec.acls.handle.html#sec.acls.handle.defacl.eff Abschnitt „Auswirkungen einer Standard-ACL“]).
Am konkreten Beispiel heißt dies, dass alle Zugriffsberechtigungen, die nicht im mode-Wert enthalten sind, aus den entsprechenden ACL-Einträgen entfernt werden.
Aus dem ACL-Eintrag der „group class“ wurden keine Berechtigungen entfernt, allerdings wurde der mask-Eintrag dahin gehend angepasst, dass Berechtigungsbit, die nicht mit mode gesetzt werden, maskiert werden.
Auf diese Weise ist sichergestellt, dass Anwendungen, zum Beispiel Compiler, reibungslos mit ACLs interagieren können.
Sie können Dateien mit beschränkten Zugriffsberechtigungen erstellen und diese anschließend als ausführbar markieren.
Über den mask-Mechanismus ist gewährleistet, dass die richtigen Benutzer und Gruppen die Dateien wie gewünscht ausführen können
ACL-Auswertungsalgorithmus
Bevor ein Prozess oder eine Anwendung Zugriff auf ein durch eine ACL geschütztes Dateisystemobjekt erhält, wird ein Auswertungsalgorithmus angewandt
- Die ACL-Einträge werden grundsätzlich in der folgenden Reihenfolge untersucht: „owner“, „named user“, „owning group“ oder „named group“ und „other“
- Über den Eintrag, der am besten auf den Prozess passt, wird schließlich der Zugriff geregelt
- Berechtigungen werden nicht akkumuliert
- Komplizierter werden die Verhältnisse, wenn ein Prozess zu mehr als einer Gruppe gehört, also potenziell auch mehrere group-Einträge dazu passen können
- Aus den passenden Einträgen mit den erforderlichen Berechtigungen wird per Zufallsprinzip ein Eintrag ausgesucht
- Für das Endresultat „Zugriff gewährt“ ist es natürlich unerheblich, welcher dieser Einträge den Ausschlag gegeben hat
- Ähnliches gilt, wenn keiner der passenden group-Einträge die erforderlichen Berechtigungen enthält
- In diesem Fall löst ein per Zufallsprinzip ausgewählter Eintrag das Ergebnis „Zugriff verweigert“ aus
ACL-Unterstützung in Anwendungen
Mit ACLs können sehr anspruchsvolle Berechtigungsszenarien umgesetzt werden, die den Anforderungen moderner Anwendungen gerecht werden
- Das traditionelle Berechtigungskonzept und ACLs lassen sich geschickt miteinander kombinieren
- Die grundlegenden Dateibefehle (cp, mv, ls usw.) unterstützen ACLs ebenso wie Samba und Konqueror
- Viele Editoren und Dateimanager bieten jedoch keine ACL-Unterstützung
- Beim Kopieren von Dateien mit Emacs gehen die ACLs der entsprechenden Dateien beispielsweise noch verloren
- Wenn Dateien mit einer Zugriffs-ACL im Editor bearbeitet werden, hängt es vom Backup-Modus des verwendeten Editors ab, ob die Zugriffs-ACL nach Abschluss der Bearbeitung weiterhin vorliegt
- Schreibt der Editor die Änderungen in die Originaldatei, bleibt die Zugriffs-ACL erhalten
- Legt der Editor eine neue Datei an, die nach Abschluss der Änderungen in die alte umbenannt wird, gehen die ACLs möglicherweise verloren, es sei denn, der Editor unterstützt ACLs
- Mit Ausnahme von Star Archiver gibt es derzeit keine Backup-Anwendungen, bei deren Verwendung die ACLs erhalten bleiben
Vererbung von Gruppenrechten
Wie können Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden
Problemstellung
Das Problem der Vererbung von GIDs und Gruppenrechten tritt z. B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen
- Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das "chmod"-Kommando vornehmen müsste
Offenbar ist das Thema weniger trivial, als man meinen möchte
- Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen
- Das stimmt so leider nicht - und so mancher beginnt dann mit \1 zu experimentieren
- Was auch nicht hilft, weil das nur einmalige - wenn auch rekursive - Änderungen im betroffenen Zweig des Dateibaums herbeiführt
- Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten
Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen
- Wir wollen hier aber eine native Lösung für beschreiben
Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit
Vorgehen
Wir nehmen zwei User eines Systems - "alpha" (uid 1001; dieser User wird der Entwicklunsgleiter) und "beta" (uid 1002)
- Beide seine Mitglieder der Gruppe "users" (gid 100)
- umask habe den Standardwert
umask 022
- Was ist nun zu tun?
Schritt 1: Anlegen einer gemeinsamen Usergruppe Als root: Anlegen einer neuen Gruppe "entwickler" (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z. B. mit Hilfe von Yast; ansonsten mit "groupadd" und "usermod -A" - siehe die man-Seiten)
Schritt 2: Check, ob ACLs für das Filesystem aktiviert sindAls root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option "acl" gemounted wird
- In der Datei "/etc/fstab" sollte sich dafür ein Eintrag der Form
/dev/myFileSystem /myMountPoint ext4 acl,user_xattr 1 2
finden. "myFileSystem" steht hier für das betroffene Filesystem. "/myMountPoint" steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird
- Entscheidend ist die Option "acl"
Schritt 3: Anlegen des Verzeichnisses für die gemeinsame EntwicklungsarbeitAls root oder Entwicklungsleiter "alpha": Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll
mkdir /myMountPoint/Entwicklung
Danach Ändern der Gruppe und der Rechte
chgrp entwicklung /myMountPoint/Entwicklung chmod 775 /myMountPoint/Entwicklung
Schritt 4: Setzen des SetGID-BitAls Entwicklungsleiter "alpha":
chmod g+s /myMountPoint/Entwicklung
Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses "/myMountPoint/Entwicklung" angelegt werden, die die Gruppenzugehörigkeit zur Gruppe "entwicklung"
Schritt 5: Setzen der ACL-MaskeAls Entwicklungsleiter "alpha":
cd /myMountPoint4 setfacl -m m::rwx Entwicklung
Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis "Entwicklung"
Schritt 6: Setzen der Default-Rechte für künftige Dateien und UnterverzeichnisseAls Entwicklungsleiter "alpha":
cd /myMountPoint setfacl -dm g:entwicklung:rwx Entwicklung
Schritt 7: Prüfen der Rechte für neue Dateien und UnterverzeichnisseAls Gruppenmitglied "beta":
cd /myMountPoint/Entwicklung touch test ls -l -rw-rw-r--+ 1 beta entwicklung 0 20. Jul 20:18 test
mkdir testdir ls -l drwxrwsr-x+ 2 beta entwicklung 4096 20. Jul 21:20 testdir
touch testdir/test2 ls -l testdir -rw-rw-r--+ 1 beta entwicklung 0 20. Jul 21:22 test2
Problembehebung
Anhang
Siehe auch
Dokumentation
Man-Pages
Info-Pages
Links
Projekt
Weblinks
- https://wiki.ubuntuusers.de/ACL/
- http://wiki.ubuntuusers.de/chmod
- http://wiki.ubuntuusers.de/ACL
- http://acl.bestbits.at