Die klassischen Dateirechte bestimmen, wer eine Datei lesen, verändern oder ausführen darf. ACLs ermöglichen zusätzliche Berechtigungen für einzelne Benutzer und Gruppen. Trotzdem kann eine Änderung scheitern, obwohl die Rechte scheinbar passen.
Eine mögliche Ursache sind Dateiattribute: besondere Eigenschaften, mit denen das Dateisystem das Verhalten einer Datei oder eines Verzeichnisses beeinflusst. Sie können Änderungen verhindern, Schreibzugriffe auf das Anhängen beschränken oder technische Eigenschaften wie Kompression steuern. Welche Attribute tatsächlich unterstützt werden, hängt vom Dateisystem ab.
Dateiattribute ergänzen damit das Berechtigungsmodell. Sie ersetzen weder eine sinnvolle Rechtevergabe noch eine Datensicherung.
Was mit „Dateiattributen“ gemeint ist
Der Begriff „Dateiattribute“ kann allgemein sämtliche Eigenschaften einer Datei beschreiben. In diesem Beitrag geht es jedoch um die besonderen Dateisystem-Flags, die sich mit lsattr anzeigen und teilweise mit chattr verändern lassen.
Technisch werden sie auch als Inode-Flags bezeichnet. Sie gehören zum Dateiobjekt beziehungsweise zum Verzeichnis und beeinflussen, wie das Dateisystem damit umgeht.
Die wichtigsten Ebenen lassen sich so unterscheiden:
| Mechanismus | Zentrale Frage |
|---|---|
| Eigentümer und Gruppe | Welchem Benutzer und welcher Gruppe ist das Objekt zugeordnet? |
| Klassische Rechte und ACLs | Welche Zugriffe sind für die jeweilige Identität erlaubt? |
| Dateiattribute | Welche besonderen Regeln oder Eigenschaften gelten für das Objekt? |
Ein Dateiattribut vergibt also nicht einfach ein weiteres Lese- oder Schreibrecht. Es kann einen Vorgang zusätzlich beschränken oder dessen technische Verarbeitung verändern.
Schreibrecht bedeutet nicht uneingeschränkte Veränderbarkeit
Angenommen, Anna besitzt eine Datei und hat daran Lese- und Schreibrecht.
Nach dem klassischen Berechtigungsmodell darf sie deren Inhalt verändern. Ist jedoch zusätzlich das Attribut „unveränderlich“ gesetzt, reicht das Schreibrecht nicht mehr aus: Die Datei kann nicht regulär zum Schreiben geöffnet werden.
Der Unterschied lautet:
- Die Dateirechte erlauben Anna grundsätzlich das Schreiben.
- Das Dateiattribut verhindert die entsprechende Änderung am Objekt.
Ein gewöhnliches Schreibrecht hebt das Attribut nicht auf. Um die Datei wieder regulär bearbeiten zu können, muss zuerst die zusätzliche Einschränkung durch einen ausreichend berechtigten Prozess entfernt werden.
Das Attribut „unveränderlich“: Schutz vor Änderungen
Das bekannteste Attribut ist immutable, dargestellt durch den Buchstaben i.
Das Dateiattribut
ischützt einzelne Dateien oder Verzeichnisse vor Änderungen, unabhängig von den gewöhnlichen Schreibrechten. Auch wenn immatiable nach Immutable Distributionen klingt, schützen sie dagegen ganze Systembereiche, etwa durch schreibgeschützte Mounts, und stellen Änderungen über kontrollierte Systemupdates bereit.
Ist es gesetzt, werden insbesondere folgende Vorgänge verhindert:
- Die Datei zum Schreiben öffnen und ihren Inhalt verändern.
- Die Datei löschen oder umbenennen.
- Zusätzliche Hardlinks auf die Datei anlegen.
- Viele Metadaten ändern, beispielsweise Eigentümer oder Berechtigungen.
Die Wirkung geht damit über ein entferntes Schreibrecht hinaus. Ein Dateieigentümer könnte sich gewöhnliches Schreibrecht normalerweise wieder geben. Eine unveränderliche Datei unterliegt dagegen einer zusätzlichen Sperre, die besondere Befugnisse zum Aufheben benötigt.
Lesen bleibt eine eigene Frage
„Unveränderlich“ bedeutet nicht „vertraulich“.
Das Attribut verhindert keine Lesezugriffe, die durch die übrigen Zugriffsregeln erlaubt sind. Es verschlüsselt die Datei auch nicht. Eine unveränderliche Datei kann daher weiterhin lesbar sein.
Das Attribut schützt vor bestimmten Veränderungen, nicht vor der Kenntnisnahme des Inhalts.
Kein vollständiges Einfrieren eines laufenden Systems
Das nachträgliche Setzen des Attributs ist kein Ersatz dafür, laufende Schreibvorgänge kontrolliert zu beenden. Die Dokumentation weist ausdrücklich darauf hin, dass i und a bereits vorhandene Schreibzugriffe über offene Dateideskriptoren nicht zuverlässig nachträglich sperren.
Für ein sauberes Schutzkonzept muss deshalb auch berücksichtigt werden, welche Programme die Datei bereits geöffnet haben.
„Nur anhängen“: Vorhandene Inhalte bewahren
Das Attribut a steht für „append only“.
Eine solche Datei darf nur im Anhängemodus zum Schreiben geöffnet werden. Neue Daten können am Ende hinzukommen; das gewöhnliche Überschreiben oder Kürzen des vorhandenen Inhalts wird dadurch verhindert.
Der Unterschied zum unveränderlichen Zustand ist wesentlich:
| Attribut | Grundgedanke |
|---|---|
i | Keine regulären Änderungen an der Datei zulassen |
a | Schreibzugriffe nur zum Anhängen erlauben |
Das kann für fortlaufend ergänzte Aufzeichnungen interessant sein. Es ist aber keine automatische Garantie für fälschungssichere Protokolle: Ein ausreichend privilegierter Prozess kann das Attribut entfernen. Außerdem müssen die beteiligten Programme mit dem eingeschränkten Schreibverhalten zurechtkommen.
Auch a vergibt selbst kein Schreibrecht. Ob ein Prozess überhaupt Daten anhängen darf, hängt weiterhin von seinen sonstigen Berechtigungen ab.
Dateiattribute dienen nicht nur dem Schutz
Nicht jedes Attribut ist eine Sperre. Manche steuern die Speicherung oder beschreiben vorhandene Dateisystemeigenschaften.
Eine Auswahl:
| Attribut | Bedeutung | Wichtige Einschränkung |
|---|---|---|
i | Unveränderlich | Besondere Privilegien zum Setzen und Entfernen erforderlich |
a | Schreiben nur im Anhängemodus | Keine allgemeine Unveränderlichkeit |
A | Zugriffszeit atime nicht aktualisieren | Betrifft die Zeitstempelverwaltung |
S | Änderungen synchron schreiben | Kann das Schreibverhalten und die Leistung beeinflussen |
c | Kompression anfordern | Nur bei unterstützenden Dateisystemen wirksam |
C | Copy-on-Write für Dateidaten deaktivieren | Dateisystemspezifisch; besonders bei Btrfs zu beachten |
d | Von Sicherungen mit dump ausschließen | Kein allgemeines Ausschlusskennzeichen für alle Backup-Programme |
| e | Die Datei verwendet Extents zur Zuordnung ihrer Speicherblöcke | Technische Speichereigenschaft, kein Schreibschutz; nicht mit chattr entfernbar. |
Diese Attribute verändern unterschiedliche Aspekte des Dateisystemverhaltens. Sie sollten deshalb nicht als austauschbare Sicherheitsoptionen verstanden werden.
Insbesondere d bedeutet nicht, dass jedes Sicherungsprogramm die Datei überspringt. Die dokumentierte Bedeutung bezieht sich auf das Werkzeug dump.
Warum das Dateisystem entscheidend ist
chattr stellt eine gemeinsame Bedienoberfläche bereit. Daraus folgt jedoch nicht, dass jedes Dateisystem jedes Attribut unterstützt.
Die Dokumentation verweist ausdrücklich auf die jeweiligen Eigenschaften von beispielsweise ext4, XFS, Btrfs und F2FS. Ein Attribut kann auf einem Dateisystem wirksam sein, auf einem anderen fehlen oder besonderen Einschränkungen unterliegen.
Beispiel: Kompression
Das Attribut c beschreibt den Wunsch nach komprimierter Speicherung. Daraus darf nicht geschlossen werden, dass eine entsprechend markierte Datei auf jedem Linux-Dateisystem tatsächlich komprimiert wird.
Die Dokumentation nennt ausdrücklich, dass ext2, ext3 und ext4 dieses Attribut nicht entsprechend umsetzen. Btrfs unterstützt dagegen dateibezogene Kompression.
Beispiel: Copy-on-Write
Bei Btrfs kann C das Copy-on-Write-Verhalten für Dateidaten beeinflussen. Dabei bestehen wichtige Voraussetzungen: Das Attribut sollte auf neue oder leere Dateien angewendet werden; das nachträgliche Setzen auf bereits gefüllte Dateien ist keine einfache Umwandlung aller vorhandenen Daten.
Für den Alltag gilt daher: Erst das Attribut verstehen, dann seine konkrete Unterstützung im verwendeten Dateisystem prüfen.
lsattr und chattr: Anzeigen und Verändern
Die beiden zugehörigen Werkzeuge übernehmen unterschiedliche Aufgaben:
| Werkzeug | Aufgabe |
|---|---|
lsattr | Vorhandene Dateiattribute anzeigen |
chattr | Veränderbare Dateiattribute setzen oder entfernen |
Die Werkzeuge gehören zum e2fsprogs-Projekt. Trotz ihrer Herkunft (Dateisysteme ext2/ext3/ext4) können die zugrunde liegenden Schnittstellen auch von anderen Linux-Dateisystemen unterstützt werden.
Attribute anzeigen
lsattr bericht.txtDie Ausgabe enthält Buchstaben für gesetzte Attribute und Bindestriche an anderen Positionen. Ein i kennzeichnet beispielsweise eine unveränderliche Datei.
Bei einem Verzeichnis zeigt diese Variante dessen eigene Attribute:
lsattr -d projektOhne -d werden bei Verzeichnisargumenten normalerweise die enthaltenen Einträge aufgelistet.
Attribute gezielt verändern
Die grundlegenden Operatoren ähneln denen von chmod:
| Operator | Wirkung |
|---|---|
+ | Ausgewählte Attribute hinzufügen |
- | Ausgewählte Attribute entfernen |
= | Veränderbare Attribute auf die angegebene Auswahl festlegen |
Für eine gezielte Änderung sind + und - meist leichter nachzuvollziehen als das vollständige Festlegen mit =.
An einer entbehrlichen Testdatei lässt sich das Prinzip beispielsweise so nachvollziehen:
sudo chattr +i testdatei.txtZum späteren Aufheben:
sudo chattr -i testdatei.txtAn produktiven Konfigurationsdateien sollte eine solche Änderung erst erfolgen, wenn klar ist, welche Programme die Datei bearbeiten müssen.
Wer darf Dateiattribute ändern?
Nicht jedes Attribut benötigt dieselben Befugnisse. Grundsätzlich erfordert das Ändern von Inode-Flags die Eigentümerstellung oder entsprechende Privilegien. Für besondere Attribute gelten zusätzliche Anforderungen.
Zum Setzen und Entfernen von i und a ist unter Linux insbesondere die Capability CAP_LINUX_IMMUTABLE erforderlich. Im üblichen Administrationsmodell erfolgt dies durch einen entsprechend privilegierten Root-Prozess.
Das ist eine andere Befugnis als CAP_CHOWN:
| Capability | Zusammenhang |
|---|---|
CAP_CHOWN | Privilegierte Eigentümer- und Gruppenänderungen |
CAP_LINUX_IMMUTABLE | Setzen und Entfernen von i und a |
Dateieigentum oder Schreibrecht allein reichen deshalb nicht aus, um diese besonderen Schutzattribute beliebig aufzuheben.
Auch root muss die zusätzliche Einschränkung beachten
Die Einschränkungen von i und a gelten auch für privilegierte Prozesse. Ein gewöhnlicher Schreibzugriff wird nicht allein deshalb erlaubt, weil er von root ausgeht.
Ein ausreichend privilegierter Prozess kann jedoch das Attribut entfernen und anschließend die Datei verändern.
Das ist der entscheidende Unterschied zwischen einer wirksamen zusätzlichen Schutzregel und einem absoluten Schutz vor Administratoren: Das Attribut verhindert bestimmte Vorgänge, solange es wirksam gesetzt ist. Es entzieht einem vollständig privilegierten Administrator aber nicht grundsätzlich die Kontrolle über das System.
Dateiattribute können damit eine Hürde gegen versehentliche oder ungewollte Änderungen sein. Sie sind keine unveränderliche Sicherheitsgrenze gegenüber allen administrativen Eingriffen.
Verzeichnisse: Keine automatische Sperre des gesamten Baums
Dateiattribute können auch Verzeichnisse betreffen. Ihre Wirkung muss jedoch vom Verhalten gewöhnlicher Dateien unterschieden werden.
Ein unveränderliches Verzeichnis verhindert Änderungen an seinen Einträgen, beispielsweise das Anlegen, Löschen oder Umbenennen. Daraus folgt nicht automatisch, dass die Inhalte aller bereits vorhandenen Dateien ebenfalls unveränderlich werden. Dafür sind deren eigene Eigenschaften und Zugriffsregeln maßgeblich.
Außerdem können manche Attribute an neu erstellte Objekte vererbt werden. Das Verhalten hängt vom jeweiligen Flag und Dateisystem ab; es gibt keine allgemeine Regel „alle Attribute gelten automatisch für den gesamten Unterbaum“.
Mit chattr -R lassen sich Attribute ausdrücklich rekursiv bearbeiten. Das ist jedoch eine Massenänderung an vorhandenen Objekten und nicht dasselbe wie eine Vererbungsvorgabe.
Dateiattribute und erweiterte Attribute sind nicht dasselbe
Die ähnlich klingenden Begriffe sollten auseinandergehalten werden:
- Die hier behandelten Dateiattribute sind Inode-Flags, die über
lsattrundchattrzugänglich sind. - Erweiterte Attribute, häufig „xattrs“ genannt, verwenden eine andere Schnittstelle und speichern zusätzliche benannte Metadaten.
Die Dokumentation behandelt Inode-Flags und erweiterte Attribute ausdrücklich als unterschiedliche Mechanismen. Sie sollten deshalb nicht allein aufgrund des gemeinsamen Wortes „Attribute“ gleichgesetzt werden.
Ebenso wenig ist chattr ein Werkzeug zum Verwalten von ACL-Einträgen oder SELinux-Richtlinien.
Typische Stolperfallen im Betrieb
Ein gezieltes Schutzattribut kann zugleich einen berechtigten Arbeitsablauf verhindern.
Beispiele sind:
- Eine Konfigurationsverwaltung kann eine unveränderliche Datei nicht regulär aktualisieren.
- Ein Editor kann beim Speichern scheitern, wenn er die Datei ersetzen möchte.
- Ein Protokollierungsverfahren kann mit „nur anhängen“ zurechtkommen, während das Kürzen oder Ersetzen der Protokolldatei scheitert.
Diese Folgen ergeben sich unmittelbar aus den gesperrten Schreib-, Lösch- und Umbenennungsoperationen.
Vor dem Setzen eines Attributs sollte deshalb geklärt sein:
- Welche konkrete Änderung soll verhindert werden?
- Welche Programme müssen weiterhin mit dem Objekt arbeiten?
- Wer darf den Schutz für Wartungsarbeiten aufheben?
- Wo ist die Abweichung vom gewöhnlichen Verhalten dokumentiert?
Ein Schutzmechanismus, dessen Existenz später niemand mehr kennt, kann die Fehlersuche unnötig erschweren.
Keine Datensicherung und kein garantiertes sicheres Löschen
„Unveränderlich“ bedeutet nicht, dass eine Datei gegen Datenträgerausfälle, Dateisystemschäden oder sämtliche administrativen Eingriffe geschützt ist. Das Attribut ersetzt deshalb keine Datensicherung.
Auch auf vielversprechende Attributnamen sollte man sich nicht ungeprüft verlassen: Die Flags s für sicheres Löschen und u für Wiederherstellbarkeit werden in der Dokumentation zwar beschrieben, sind aber keine allgemein verfügbare Garantie. Insbesondere ext2, ext3 und ext4 setzen diese Funktionen nicht entsprechend um.
Für den grundlegenden Umgang mit Dateiattributen ist daher eine kleine, gut verstandene Auswahl sinnvoller als das ungeprüfte Setzen möglichst vieler Flags.
Fazit: Besondere Eigenschaften gezielt einsetzen
Dateiattribute ergänzen die Linux-Rechteverwaltung um Regeln für das Verhalten einzelner Dateien und Verzeichnisse. Besonders anschaulich sind „unveränderlich“ und „nur anhängen“: Sie können bestimmte Änderungen verhindern, obwohl die gewöhnlichen Zugriffsrechte sie erlauben würden.
Andere Attribute betreffen dagegen die Speicherung, Zeitstempel oder technische Verarbeitung. Ihre Wirkung hängt vom Dateisystem und teilweise vom Zustand des Objekts ab.
Der wichtigste Grundsatz lautet deshalb: Dateirechte bestimmen, welche Zugriffe einer Identität erlaubt sind; Dateiattribute können zusätzlich das Verhalten des Objekts begrenzen oder verändern. Wer diese Ebenen auseinanderhält, kann Attribute als gezielte Ergänzung einsetzen – ohne sie mit einem vollständigen Sicherheitskonzept zu verwechseln.
