Linux/Zugriffskontrollliste

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 Unterverzeichnis­se 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 ent­halten 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öl­lig 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ögli­chen 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 Berechti­gungsmodelle 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 Win­dows betrieben werden
• Das Linux-System stellt den Windows-Clients Datei- und Druckdienste über Sam­ba 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) kon­figuriert 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 Zu­weisen von Berechtigungen im Dateisystem: den Eigentümer (owner), die Eigentümergruppe (owning group) und andere Benutzer (other) Pro Benutzerklasse können jeweils die drei Berech­tigungsbit zum Lesen (r), Schreiben (w) und Ausführen (x) 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 Be­rechtigungen 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 Be­zeichner für den Benutzer oder die Gruppe, auf den bzw. die sich der Eintrag bezieht, und Be­rechtigungen Für einige Eintragstypen ist der Bezeichner für die Gruppe oder die Benutzer nicht definiert

Anhang

Siehe auch

• Linux/Zugriffskontrollliste
• Linux/Zugriffskontrolllisten (ACL)

TMP

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

Links

Weblinks

1. https://wiki.ubuntuusers.de/ACL/
2. http://wiki.ubuntuusers.de/chmod
3. http://wiki.ubuntuusers.de/ACL
4. http://acl.bestbits.at
5. Manualpages für getfacl(1), acl(5) und setfacl(1)