Linux/Zugriffsrechte

Zugriffsrechte

Besitzrechte

Jeder UNIX-Benutzer hat eine Benutzerkennung (user id, kurz: UID) mit der er sich gegenüber dem Betriebssystem identifiziert. Außerdem gehört jeder UNIX-Benutzer mindestens einer Gruppe an (primäre Gruppe) und besitzt damit eine Group-ID, (kurz: GID).

Über Gruppen lassen sich die Zugriffsrechte eines einzelnen Benutzers erweitern.

So könnte man beispielsweise alle Benutzer standardmäßig in die Gruppe Users stecken.

Diese Gruppe hat standardmäßig nur sehr wenig Zugriffsrechte. Damit ein User dieser Gruppe nun z.B. auf das Modem zugreifen darf, kann man ihn zusätzlich auch noch in die Gruppe dialout eintragen.

Die Use-ID und die Gruppenzugehörigkeiten lassen sich dem Befehl id anzeigen.

> id

uid=1000(dirkw) gid=500(privat)\
Gruppen=0(root),14(uucp),16(dialout),33(video),100(users)

Jede Datei gehört also immer zu genau einem Benutzer, und genau zu einer Gruppe, die bei der Erzeugung einer Datei eingetragen werden.

Besitzer ändern: chown

chown·User·Dateiliste

Übertragen einer Datei an einen anderen Benutzer. Der Benutzer wird vollständiger Eigentümer der Datei. Der alte Eigentümer verliert sie.

Beispiel

chown·markus·datei1

Datei dat1 wird an markus übertragen.

Die bit UID, GID und Sticky nehmen eine Sonderstellung ein - sobald eine Datei an einen anderen Be­nutzer übertragen wird, werden sie zur Sicherheit automatisch ge­löscht.

Der Befehl chown kann nur von root ausgeführt werden

Gruppen ändern

chgrp·Gruppe·Dateiliste

Ändern der Gruppenzugehörigkeit einer Datei.

Es kann entweder die Gruppennummer oder der Gruppenname angegeben werden.

UNIX-Zugriffsrechte

Datei:Grafik2.png

Um den Zugriff auf Dateien zu regeln, können die Rechte an den Besitzer, die Gruppe und alle anderen vergeben werden.

r	read (Lesen)
w	write (Schreiben)
x	execute (Ausführen)

R	W	X	R	W	X	R	W	X
user			group			others

Diese können mit dem Befehl ls -l angezeigt werden.

> ls -l -rw-r----- 1 dirkw privat 2374 2006-10-16 16:15 addressbook.odb

Die Datei addressbook.odb wurde am 16.10.2006 um 16:15 erstellt. Sie ist 849093 Bytes groß und ge­hört dem Benutzer "dirkw" sowie der Gruppe "privat". Das Rechtefeld schlüsselt sich wie folgt auf:

-	rw-	r--	---
Dateityp	Eigentümers	Gruppe	alle Anderen
Es handelt sich um eine normale Datei.	Der Eigentümer darf die Datei lesen, ändern, aber nicht ausführen	Die Gruppe darf die Da­tei nur lesen	Alle anderen haben kei­nen Zugriff auf die Datei

Zugriffsrechte ändern mit chmod

chmod·Modus·Dateiliste

Einstellen der Zugriffsrechte einer Datei. Dies kann im symbolischen oder numerischen Modus durchgeführt werden.

Symbolischer Modus

Modus = BereichOperandBerechtigung

Bereich	u (user) Eigentümer g (group) Gruppe o (others) Übrige Benutzer a(all) oder keine Angabe ändert alle Bereiche
Operand	+ Recht hinzufügen - Recht wegnehmen = Setzt neue Rechte und löscht alle bisherigen
Berechtigung	r Read w Write x eXecute t(sTicky bit) schützt Datei oder verhindert das löschen einer Datei von Nicht-Eigentümern s(Set user id) setzt Benutzer- oder Gruppen-ID bei der Ausführung

Beispiele

chmod·+x·datei	Ausführungsrecht für alle hinzufügen
chmod·go-w·datei	Schreibrecht nur noch für User
chmod·g+rwx·datei	Volle Rechte für Gruppe
chmod·ugo-rwx·datei	Allen alle Rechte entziehen

Kombinationen mit verschiedenen Zugriffsrechten für verschiedene Rollen können kommagetrennt ange­geben werden:

$ chmod u=rw,g=rw,o=r ktoNr

$ ls -l
-rw-rw-r-- 1 anna users 9 18. Okt 13:20 ktoNr

Numerischer Modus

Systemintern werden die Zugriffsrechte numerisch verwaltet. Diese Methode kann auch zum Setzen der Rechte verwendet werden. Die erste Ziffer Bezeichnet die Schutzbit, die zweite Rech­te des Eigentümers, die dritte die Gruppenrechte und vierte Ziffer die Rechte aller anderen Benutzer. Die Zahl errechnet sich durch addieren folgender Okalwerte:

Datei:Grafik5.png

SUID	SGID	STI	R	W	X	R	W	X	R	W	X
4	2	1	4	2	1	4	2	1	4	2	1
special rights			User			Group			Others

Beispiel

chmod 777·datei 	rwx rwx rwx
chmod 750 	rwx r-x ---
chmod 1750 	rwx r-w --t

Special Rights

Um den Zugriff noch genauer zu regeln, gibt es drei weiter Schutzbit:

SUID	SGID	STI	R	W	X	R	W	X	R	W	X
special rights			User			Group			Others

Set User ID (SUID)

Wenn das SUID-Bit (Set User ID) gesetzt ist, behält das Programm für die Dauer der Ausführung die Rechte des Programmeigentümers und nicht jene dessen, der die Programme aufruft.

Setzen

chmod·u+s·datei

Anzeige

"S" statt "X" bei den User-Rechten:

-rwsr-xr-x 1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd

Ist zugleich das Ausführungsrecht (x) gesetzt, wird ein kleines 's' angezeigt, ansonsten ein großes 'S'.

Beispiel

Alle Benutzer sind in einer speziellen Datei gespeichert, die nur der Superuser ändern darf - sonst könnte ja jeder einen neuen Benutzer eintragen.

Jeder Benutzer kann aber sein Passwort ändern, das auch in dieser Datei steht. Dazu muss er schreibend auf die Datei zugreifen - obwohl er dazu keine Berechtigung besitzt.

Das Programm "passwd" gehört dem Superuser, hat das SUID-Bit gesetzt und kann so auf die User-Datei schreibend zugreifen.

Set Group ID (SGID)

Wenn das SGID-Bit (Set Group ID) gesetzt ist, hat das Programm die Rechte der Gruppe, zu der es gehört. Dieses Feature wird z. B. beim Drucker-Spooling verwendet.

Bei Dateien ohne Ausführungsrecht sorgt dieses Bit dafür, dass die Datei nur von einem Prozess geöffnet werden kann.

Bei Verzeichnissen hat das SGID-Bit eine andere Aufgabe. Dateien, die in das Verzeichnis kopiert oder erstellt werden, automatisch die Gruppe des Verzeichnisses erhalten (man muss also nicht mehr explizit die Gruppe setzen, um den Mitgliedern einer Gruppe Zugriff zu ermöglichen).

Setzen

chmod·g+s·datei

Anzeige

"s" statt "x" bei den Gruppen-Rechten

drwxrws--- 2 tux archive 48 Nov 19 17:12 backup

Ist zugleich das Ausführungsrecht (x) gesetzt, wird ein kleines 's' angezeigt, ansonsten ein großes 'S'.

STICKY Bit

Das STICKY-Bit sollte früher den Systemdurchsatz verbessern. Programme, bei denen dieses Bit gesetzt ist, verbleiben nach dem ersten Aufruf im Speicher und starten bei den folgenden Aufrufen schneller. Heute ist das nicht mehr nötig.

Bei Verzeichnissen dient dieses Bit der Systemsicherheit.

Auch wenn im Verzeichnis für alle User Schreibrecht existiert (= Löschen und Anlegen von Dateien), können bei gesetztem Sticky-Bit nur Dateien gelöscht werden, die einer folgenden Bedingungen genügen: # die Datei gehört dem Benutzer, der sie löschen will

1. das Verzeichnis, in dem die Datei liegt, gehört dem Benutzer
2. der Benutzer hat Schreibrecht für die Datei
3. der Superuser will die Datei löschen

Setzen

chmod·+t·datei

Anzeige

t" statt "x" bei den "Others"-Rechten

drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp

Ist zugleich das Ausführungsrecht (x) gesetzt, wird ein kleines 't' angezeigt, ansonsten ein großes 'T'.

Vorgaben setzen mit umask

umask Modus

Das Kommando umask setzt Standardeinstellung für Zugriffsrechte für alle Dateien, die nach Aufruf von umask erzeugt werden.

So muss nicht jedesmal des chmod-Kommando aufrufen, wenn einen Datei erstellt wurde. Auf bestehende Dateien hat das Kommando keinen Einfluss.

Der dreistellige Zahlenwert (für User, Group und Others) ist das Komplement der Angabe von chmod, d. h. hier wird festgelegt, welches Bit nicht gesetzt werden soll.

Stellen Sie sich vor, sie ziehen den Wert des umask-Modus vom Maximalwert 777 ab. Sie erhalten dann die Zugriffsrechte.

Beispiele

umask 022	7 7 7- 0 2 2= 7 5 5	rwx r-x r-x
umask 027	7 7 7- 0 2 7= 7 5 0	rwx r-x ---
umask 177	7 7 7- 1 7 7= 6 0 0	rw- --- ---

Zugriffskontrolllisten (ACLs)

In der Unixwelt versteht man unter Access Control List eine Erweiterung der „normalen“ Zugriffssteuerung auf Ebene des Benutzer-Gruppe-Welt-Modells.

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 angewendet 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.

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 Ein­trag 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 Berechtigun­gen 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 Ein­trag other definiert die Berechtigungen aller anderen Benutzer.

Der Eintrag mask schränkt die durch die Einträge „named user“, „named group“ und „owning group“ ge­währten Berechtigungen ein, indem durch ihn festgelegt werden kann, welche der Berechtigungen in die­sen Einträgen wirksam und welche maskiert sind.

Sind Berechtigungen sowohl in einem der oben genann­ten 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 Verzeich­nisse 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 her­kö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

Datei:Grafik3.png

Im Fall einer minimalen ACL – ohne „mask“ – werden die „group class“-Berechtigungen dem ACL-Eintrag „owning group“ zugeordnet.

Dies ist in [../../../material/linux/aaa_projekte/skript/tmp/sec.acls.handle.html#fig.acls.map.mini Abbildung „Minimale ACL: ACL-Einträge vs. Berechtigungsbit“] dargestellt. 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

Datei:Grafik4.png

Durch diese Art der Zuordnung ist die reibungslose Interaktion von Anwendungen mit und ohne ACL-Un­terstützung gewährleistet.

Die Zugriffsberechtigungen, die mittels der Berechtigungsbit festgelegt wur­den, 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 Zugriffsberechti­gungen 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 Grup­pe den Schreibzugriff (2) verweigert und allen anderen Benutzern überhaupt keine Berechtigungen erteilt (7).

Die entsprechenden Berechtigungsbit werden von umask maskiert oder deaktiviert. Weitere Infor­mationen 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 Informa­tionen 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 ge­trennt).

Im letzten Teil geben Sie den Namen des Verzeichnisses an, für das diese Änderungen gelten sol­len. 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 wirk­sam sind. Außerdem passt setfacl vorhandene mask-Einträge automatisch an die geänderten Einstellun­gen an, es sei denn, Sie deaktivieren diese Funktion mit -n. „mask“ legt die maximal wirksamen Zugriffs­berechtigungen 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 ausge­geben 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 Schreibzu­griff. Solche Berechtigungsbit würden normalerweise bedeuten, dass die „owning group“ (hier projec­t3) ebenfalls Schreibzugriff auf das Verzeichnis mydir hätte.

Allerdings sind die wirklich wirksamen Zu­griffsberechtigungen 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 (siehe [../../../material/linux/aaa_projekte/skript/tmp/sec.acls.handle.html#tab.mask Tabelle „Maskierung von Zugriffsberechtigungen“]).

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, lie­fert Ihnen bereits die Ausgabe des Befehls ls den Hinweis darauf, dass die mask-bit entsprechend ange­passt 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 Er­stellung 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 Unterver­zeichnisse unterschiedlich vererbt:* Ein Unterverzeichnis erbt die Standard-ACL des übergeordneten Verzeichnisses sowohl als seine ei­gene 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 Zugriffs­berechtigungen 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 Be­rechtigungen abgezogen und das Ergebnis wird dem neuen Objekt zugewiesen.

Existiert eine Standard-ACL für das übergeordnete Verzeichnis, entsprechen die dem neuen Objekt zugewiesenen Berechtigungs­bit der Schnittmenge aus den Berechtigungen des mode-Parameters und den in der Standard-ACL festge­legten 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 Be­fehl 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 wir­ken sich nur beim Erstellen von Dateisystemobjekten aus. Diese neuen Objekte übernehmen Be­rechtigungen nur aus der Standard-ACL ihres übergeordneten Verzeichnisses.

1. 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 un­tergeordneten Objekte weitervererbt, ist ebenfalls dieselbe. 

1. 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, mas­kiert 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 er­hält, wird ein Auswertungsalgorithmus angewendet.

Die ACL-Einträge werden grundsätzlich in der folgen­den 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. Berechtigun­gen 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 Zufalls­prinzip 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 ge­schickt 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.

Weitere Informationen

Ausführliche Informationen zu ACLs finden Sie unter http://acl.bestbit.at/.

Weitere Informationen finden Sie außerdem auf den Manualpages für getfacl(1), acl(5) und setfacl(1).

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

"chgrp -R"     und     "chmod -R"

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. Z.B.:

mkdir   /myMountPoint/Entwicklung

Danach Ändern der Gruppe und der Rechte

chgrp   entwicklung     /myMountPoint/Entwicklung chmod   775     /myMountPoint/Entwicklung

Schritt 4: Setzen des SetGID-BitsAls 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

http://wiki.ubuntuusers.de/chmod#SGID-Bithttp://wiki.ubuntuusers.de/ACL#Verzeichnisse

== ext3-/ext4-Dateiattribute

aktualisieren

+ e

Status?

==

Zusätzlich zu der aus dem Dateisystemkonzept von Unix übernommenen Methode, die Datensicherheit durch Reglementierung der Zugriffsrechte zu erhöhen, bietet das ext2fs mit seinen Dateiattributen weitere Mechanismen an, die den Datenschutz in verschiedenen Richtungen verbessern.

Dateien lassen sich seit ext2-0.5a durch die Attribute a (append) und i (immutable) zusätzlich vor Verän­derungen schützen. In den I-Nodes des ext2fs steht ein vier Bytes großes Feld für „Flags zur Verfügung.

Von diesem 32 Bit großen Bereich ist zur Zeit nur die Bedeutung der ersten sieben bit für bestimmte Dateiattribute definiert, der Rest des Feldes steht für zukünftige Erweiterungen bereit. Selbst der erfahrene Linuxer ist vor Fehlern nicht gefeit. Man stelle sich nur vor, man wollte alle Dateien aus einem Unterverzeichnis löschen:

rm -rf ~/DirToDelete/ *

Das Beispiel sieht harmlos aus, birgt aber einen fatalen Fehler in sich: das Leerzeichen zwischen Pfadangabe und dem *. Verschwunden sind nicht die gewünschten Daten, sondern der komplette Inhalt des aktuellen Verzeichnisses (falls man die Berechtigung dazu besaß).

Linux bietet bekannterweise keine zuverlässige Methode des Wiederherstellens gelöschter Daten.

Dafür ermöglicht das Linux-Dateisystem ext2 die Vergabe von Attributen für Dateien und Verzeichnisse. Sicher wird man aus Bequemlichkeit meist auf diese verzichten, aber essentielle Daten lassen sich somit zuverlässig schützen.

Zum Setzen von Attributen dient das Kommando chattr, anzeigen lassen sie sich mittels lsattr.

Übersicht Datei-Attribute

a	(append) Eine mit diesem Attribut gekennzeichnete Datei kann nur durch Anhängen zusätzlicher Daten ver­ändert werden. Das überschreiben der bereits gespeicherter Daten, das Löschen, Umbenennen oder Ver­schieben ist nicht möglich.
d	(dump) Mit diesem Attribut können Dateien markiert werden, die von der inkrementellen Sicherung durch dump ausgenommen werden sollen.
i	(immutable) Eine Datei, die mit diesem Attribut ausgestattet ist, läßt sich in keiner Weise verändern. Sie kann nicht gelöscht oder umbenannt werden, es können keine Links auf sie erzeugt werden und der Inhalt der Datei lässt sich nicht überschreiben oder erweitern. Zum Setzen oder Löschen dieses Attributs sind Rootprivilegien erforderlich.
s	(secure) Durch dieses Attribut können Dateien, deren Inhalt besonders vor dem unberechtigten Zugriff an­derer Systembenutzer geschützt werden soll, zum sicheren Löschen markiert werden. Die Datenblöcke wer­den dann beim Löschen durch zufällige Daten überschrieben.
S	(Sync) Dieses Attribut veranlaßt den Kernel, jede Veränderung der I-Node synchron durchzuführen. Die ver­änderten Daten werden ungepuffert sofort auf das Speichermedium geschrieben.
u	(undelete) Noch ohne Funktion. Durch dieses Attribut soll eine Datei zukünftig auch nach dem Löschen noch intakt gehalten werden, damit das Retten der Daten durch die noch zu entwickelnde undelete-Funktion möglich ist.
c	(compressed) Noch ohne Funktion. Dieses Attribut wird einmal den Kernel veranlassen, die entsprechende Datei komprimiert zu speichern.

Veränderungen an den Dateiat­tributen können nur die Benutzer vornehmen, die auch die Datei selbst ver­ändern dürfen (also schreibbe­rechtigt sind).

Nur Anhängen

Beim traditionellen System der Zugriffsregelung wird das Schreiben ganz allgemein entweder erlaubt oder verboten.

Die Erlaubnis erstreckt sich uneingeschränkt auf das Schreiben an jeder beliebigen Stelle der Datei.

Damit bedeutet Schreiben in diesem Sinne sowohl Schreiben als auch Überschreiben.

Das Betriebssystem kann, dem POSIX-Standard entsprechend, zwischen wahlfreiem Schreiben und dem ausschließlichen Schreiben am Ende einer Datei, also dem Anhängen von Daten, unterscheiden.

Das ext2-Dateisystem unterstreicht diese Unterscheidung und führt damit ein zusätzliches Sicherheits­merkmal ein. Durch das append-Attribut a wird jeder Schreibzugriff automatisch am Ende der Datei aus­geführt; es gibt dann keine Möglichkeit, die Schreibposition an eine andere Stelle zu setzen.

Zusätzlich kann eine durch dieses Attribut gesicherte Datei nicht gelöscht, gelinkt, umbenannt oder ver­schoben werden. Dieser Schutz läßt sich auch durch Rootprivilegien nicht umgehen.

Das append-Attribut kann jeder Benutzer für seine eigenen Dateien ändern. Mit Rootprivilegien ist auch das Ändern fremder Dateiattribute möglich.

Einfrieren

Allein die Superuserin kann eine Datei im ext2-Dateisystem völlig einfrieren.

Das immutable-Attribut ver­bietet jeden Schreibzugriff auf eine Datei. Zusätzlich sind wie beim append-Attribut Löschen, Linken, Um­benennen und Verschieben der Datei unmöglich.

Der normale Eigentümer einer Datei kann das immutable-Attribut nicht verändern.

Damit kann ihm durch dieses Attribut jede Veränderung wirksam verboten werden. Diese Restriktion macht für natürliche Sys­tembenutzer keinen Sinn.

Für news, mail und ähnliche Systemaccounts, die sich dadurch auszeichnen, daß viele Programme zur Laufzeit mit den Rechten dieser ``Eigentümer arbeiten, bietet immutable wirksam zusätzliche Sicherheit vor Mißbrauch.

Das immutable-Attribut selbst kann mit Rootprivilegien wieder gelöscht werden.

Einen absoluten Schutz vor unberechtigter Veränderung einer Datei bietet also auch dieses Attribut nicht.

Sicheres Löschen

Beim Löschen einer Datei wird in den Linux-Dateisystemen normalerweise der Verzeichniseintrag gelöscht und die Inode sowie die Datenblöcke freigegeben, wenn der Verzeichniseintrag der letzte für diese Datei war.

Die freigegebenen Datenblöcke werden bei irgendeiner Gelegenheit durch einen anderen Prozeß wieder belegt.

Es ist kein Geheimnis, daß der Inhalt solcher Datenblöcke von dem Prozeß, dem sie zugeteilt wor­den sind, auch gelesen werden kann.

Wenn ein Prozeß den Datenblock liest, bevor er eigene Daten hin­eingeschrieben hat, kann er fremde Daten darin finden.

Um diese unbeabsichtigte Weitergabe von Daten zu verhindern, bietet das ext2-Dateisystem die Möglich­keit, alle von einer Datei belegten Datenblöcke durch zufällige Zeichen zu überschreiben, bevor sie beim Löschen für andere Prozesse freigegeben werden.

Das secure-Attribut schickt die Dateien beim Löschen also durch einen elektronischen Reißwolf.

Sie sollten allerdings bedenken, daß häufig bei der Bearbeitung von Dateien durch andere Programme Ko­pien angelegt werden, die nicht automatisch mit dem secure-Attribut ausgestattet sind.

Synchrones Schreiben

Indem Linux einen Großteil des freien Arbeitsspeichers als Puffer für die relativ langsamen Festplattenzu­griffe nutzt, wird die Geschwindigkeit des System spürbar erhöht.

Diese erhebliche Leistungssteigerung geht zu Lasten der Datensicherheit. Wenn das System nämlich aus irgendeinem Grund abstürzen sollte, sind die im Puffer veränderten, aber noch nicht auf die Festplatte zu­rückgeschriebenen Daten verloren.

Besonders unangenehm wird es, wenn es sich bei den verlorenen Daten um Strukturinformation handelt.

In diesem Fall kann auch die bereits sicher auf der Festplatte befindliche Information unzugänglich wer­den.

Der Verzicht auf die Datenpufferung kommt nicht ernsthaft in Betracht.

Ein Betriebssystem, das mehrere Benutzer und viele Prozesse gleichzeitig bedienen soll, braucht ein sehr schnelles Dateisystem.

Um wenigstens die Sicherheit der bereits auf Festplatte gespeicherten Daten zu optimieren, bietet das ext2-Dateisystem die Möglichkeit, mit dem synchron-Attribut die ungepufferte Verwaltung der Metadaten einer Datei zu erreichen.

Verzeichnis und Inode werden unmittelbar nach ihrer Veränderung auf die Festplatte geschrieben.