Die Dateirechte sind Unix-weit identisch, aber teilweise werden sie durch ACLs noch erweitert, um die Rechtevergabe noch feiner einteilen zu können.

In der Praxis gibt es aber kaum Szenarien, wo das nötig ist, wenn man das Prinzip der Unix-Standardrechte erst einmal begriffen hat.

Noch etwas: Dateierweiterungen sind Unix völlig egal: Man kann problemlos ein Programm "Textdatei.txt" nennen, es ausführbar machen und dann ausführen. Dateierweiterungen sind auch nicht so festgelegt wie unter DOS - der Punkt ist ein ganz normaler Bestandteil des Dateinamens und nimmt keine Sonderrolle ein.

Unter UNIX allgemein gibt "ls -l" für jede Datei etwa so etwas aus:

-rwxr-xr-x   2 root     root        13876 Nov 17 15:13   myfile

Der Attribut-Zeichenkette (10 Zeichen) gibt Auskunft darüber, wer mit dieser Datei was machen darf und was für ein Typ es ist. Die Rechte-Zeichenkette teilt sich in 1+3+3+3 Zeichen auf. Kurzgefasst:

• - Typ (directory, block device, character device, fifo, socket, - normale Datei)

• rwx Was darf der Besitzer der Datei mit ihr machen (bzw. was hat er sich selbst erlaubt)?

• r-x Was dürfen Mitglieder der Gruppe mit der Datei machen?

• r-x Was darf der "Rest der Welt" mit der Datei machen?

Die Zeichenfolge "rwx" steht beziehungsweise für "Read", "Write", und "eXecute":

Zusätzlich gibt es noch folgende Attribute, die i.d.R. statt dem "x" eingesetzt werden, wo sie auftauchen:

• t (das "sticky bit", für Verzeichnisse)

  • Man darf nur seine eigenen Dateien löschen. Sinnvoll für /tmp-Verzeichnisse. Natürlich müssen auch die sonstigen Rechte stimmen, damit man überhaupt schreiben/lesen darf.

• s ("set user id" oder "set group id" für Programme, "set group id" für Verzeichnisse), siehe SetUid.

  • Bei einem Verzeichnis, das set group id gesetzt ist, werden alle Dateien und Verzeichnisse, die darin neu angelegt werden, derselben Gruppe wie das Verzeichnis angehören. Wichtig: Für bereits woanders angelegte und dann dort hinein verschobene Dateien gilt dies nicht!

Zusätzlich zu den Rechten gibt es je nach DateiSystem noch DateiAttribute, die besondere Verhaltensweise regeln.

Oft werden die Dateirechte auch in Form von Ziffernkombinationen angeben, meist in Verbindung mit dem Befehl chmod.

Hier einmal die gängigsten:

Wie kommt man auf diese Ziffernfolgen? Wenn man die Buchstabenkürzel für die Dateirechte rechts von den Ziffern als Binärzahl liest, wobei ein beliebiger Buchstabe für 1 und das Minuszeichen für 0 steht, ist diese Binärzahl gleich der Ziffernfolge, wenn man diese als Oktalzahl liest. Also: Bits für User, Gruppe und Rest in Dreiergruppen lesen und in Oktalziffern wandeln. chmod 0755 dateiname wandelt alle Rechte auf einmal auf rwxr-xr-x. Die erste der vier Ziffern steht für die SetUid/!SetGid/Sticky-Bits.

Oder etwas einfacher erklärt: 4=r 2=w 1=x, die Kombinationen erhält man durch Addition. Für die erste Ziffer gilt: 4=SetUid 2=SetGid 1=Sticky.

Führende Nullen kann man auch weglassen, d.h. 0755 = 755.

Besonderheiten

Dateien erstellen/löschen

Um eine Datei erstellen oder löschen zu können, muss man Schreibberechtigung auf das Verzeichnis haben.

Hintergrund: Eine Datei ist nichts anderes als ein Verzeichniseintrag, und um in einem Verzeichnis etwas einzutragen (oder auszutragen), muss man hineinschreiben können.

Wenn auf dem Verzeichnis das sticky-Bit gesetzt ist, muss man immer der Eigentümer der Datei sein, um sie zu löschen.

Gruppenarbeit einfach gemacht ( Private Benutzergruppen / User Private Groups (UPG) )

Wenn mehr als ein Benutzer an einem System arbeitet und diese zusammen an Dateien arbeiten sollen, kann man die Zusammenarbeit sehr erleichtern, indem man sogenannte "Private Gruppen" und "SetGID" Gruppenverzeichnisse einrichtet. Ansonsten müssen die Benutzer jedesmal per Hand die Dateirechte anpassen, anstatt sie nur in ein entsprechendes Verzeichnis zu speichern, um anderen Zugriff erlauben.

Bei privaten Gruppen, auch "User Private Groups" (UPG) genannt, ist die primäre Gruppe jedes Benutzers seine private Gruppe, in dieser ist nur der Benutzer selbst einziges Mitglied. Diese Gruppe hat den gleichem Namen und ID-Nummer wie der Benutzer selbst. Vorteilhaft ist nun, dass man die standardmäßigen Datei-Erstellungsrechte "umask" gefahrlos so einstellen kann, dass auch der Gruppe Schreibzugriff erlaubt ist (umask 002). Da eine Datei normalerweise der primären Gruppe des Erstellers zugeordnet wird, ist bei Verwendung von privaten Grupen in dieser Gruppe ja nur der Eigentümer selbst.

BeiDebian und RedHat/Fedora sind private Gruppen und umask 002 Standard.

Wenn jetzt eine Gruppe von Benutzern gemeinsam Zugriff auf Dateien haben sollen, braucht man nur ein Verzeichnis zu erstellen, es der "echten" Gruppe mit den zugehörigen Benutzern zuzuordnen und das "Set Group ID" Attribut für das Verzeichnis zu setzten. Damit werden neu erstellte Dateien in dem Verzeichnis der echten Arbeitsgruppe zugeordnet, und durch die entsprechende umask Einstellung bekommen alle Mitglieder der Gruppe auch automatisch Schreibzugriff.

Siehe Beispiel 2 (Gruppenverzeichnis).

Beispiele

Beispiel 1

Ein Verzeichnis (d) namens "Dateien" mit folgenden Attributen

drwx--x---   2 oliver   winusers       1024 Nov 17 18:00 Dateien

dürfte also von Oliver gelesen, beschrieben und betreten (rwx) werden, alle User in der Gruppe "winusers" dürfen zwar ins Verzeichnis hineinwechseln, aber haben keine Möglichkeit, den Inhalt des Verzeichnisses zu erfahren (s.u.). Alle anderen dürfen gar nichts. Diese Rechte ändern darf nur der Besitzer der Datei, hier halt oliver.

Obiges Gruppenrecht ist u.U. sehr nützlich: Man kann (als Oliver) jemandem der Gruppe erzählen, im Verzeichnis befindet sich eine Datei namens "Steuererklärung.sdc", die er -- entsprechende Rechte der Datei vorausgesetzt -- problemlos öffnen und auch verändern kann. Aber er hat keine Möglichkeit herauszufinden, daß in demselben Verzeichnis noch eine Datei namens "Steuererklärung - Version fürs Finanzamt.sdc" liegt, die ganz andere Daten enthält, da er ja den Verzeichnisinhalt nicht erfahren kann.

Einfach mal mit den Rechten rumspielen, das kann im Netzwerk sehr nützlich werden, wenn man diese flexibel einsetzt. Oliver braucht im obigen Beispiel übrigens nicht zur Gruppe winusers zu gehören, er hat seine Rechte als Dateieigentümer trotzdem ...

Beispiel 2 (Gruppenverzeichnis)

Ein Verzeichnis (d) namens "/home/share/Users" mit folgenden Attributen

drwxrws---   1 root   users           1024 Jun 19 10:43 /home/share/Users

Nehmen wir an, die User ronny und thomas gehören jeweils ihrer privaten Gruppe ronny bzw. thomas an (z.B. bei RedHat so üblich), wenn diese User nun zusätzlich der Gruppe users angehören, dann können beide über dieses Verzeichnis Dateien austauschen, ohne dass sie manuell die Gruppe der Dateien ändern müssten, da alle neuen Dateien automatisch der Gruppe users gehören (der Eigentümer bleibt immer der Ersteller der Datei und kann auch nur von root geändert werden, ein set user id für Verzeichnisse funktioniert nicht (das wäre auch nicht gut))

Wichtig: Die darüber liegenden Verzeichnisse müssen begehbar sein ('x' muss gesetzt sein).

Beispiel 3

d-wx-wx-wx   1 ftp    nobody           1024 Jun 19 10:43 write-only-directory/

setzt für others (den Rest der Welt) die Rechte einer Datei auf "write" und löscht alle anderen - so können alle zwar Dateien in diesem Verzeichnis erstellen, aber weder kann jemand ein Listing anzeigen lassen noch können User andere Dateien ändern oder löschen, da sie deren Namen ja nicht erfahren können.

Solche Rechte hat Mc-Afee z.B. auf ihrem Viren-FTP-upload-Verzeichnis benutzt - jeder kann da Viren reinschieben, aber keiner kann gucken, was drin ist, geschweige denn Dateien herunterladen. Mittlerweile akzeptieren sie Viren-Submissionen wohl nur noch per EMail.

Und nun?

OK, wie ändere ich diese Attribute? Das Programm chmod (Change file Mode) ist dafür verantwortlich. Die gängigen Dateimanager wie Konqueror, Nautilus oder der MidnightCommander können natürlich auch die Dateirechte anzeigen und ändern.

Fragen

Frage: Was mache ich eigentlich, wenn ich möchte, dass eine Gruppe von Benutzern auf einen Verzeichnisinhalt schreibend zugreifen darf, eine andere Gruppe nur lesend und der Rest gar keinen Zugriff? Geht das nur mit ACL? -- WinfriedMueller

• Nein, allerdings nur über eine Verzeichnisstruktur (in dem Fall wären ACLs evtl einfacher).
  • gruppe1 : nur lesen
  • gruppe2 : schreiben
  • gruppe3 : gruppe1+2

  • drwxr-s--- root gruppe3 foo
    drwxrwsr-x root gruppe2 foo/bar

Fiese Fehler

Ausgangssituation

root@poseidon:/# man man
man: error while loading shared libraries: libc.so.6: cannot open shared object file: Permission denied

Tja, und das als root.

Außerdem meinte der lokal laufende Apache auch generell zu allem "Permission denied", obwohl die httpd.conf und die Verzeichnisrechte (zumindest dort, wo man hinschaut ) korrekt waren.

Lösung

# ls -ld /
drwxr-xr-- 29 nemo users   4096 203-09-04 23:18 .

Aaaaaaah! - man ist suid man - und hat daher keine Rechte. Überhaupt hat alles, was nicht root oder nemo oder group users ist, ziemlich wenig Rechte, v.a. das x-Recht fehlt - ganz abgesehen davon, dass natürlich Owner/Group völlig falsch ist...

• Wer sowas baut, braucht sich ja eigentlich nicht zu wundern, von allein passiert das eher nicht

Lösung:

# chown root.root /
# chmod 755 /

Und schon verhält sich das System deutlich weniger merkwürdig.