Teil 2 Teil 1|Teil 3
Dem Thema 'Verzeichnis-Rechte' wurden im Teil 1 relativ viel Aufmerksamkeit geschenkt.
Warum das Ganze?
Auf einem Einzelplatz-System, was nun mal der Arbeitsplatz-PC ist, ist die Rechtevergabe im Home-Verzeichnis, wenn man keine Freigaben (Shares) einrichten will, nicht von so entscheidender Bedeutung. Auf einem Server ( z.B.: Zentyal oder NAS-Gerät), der naturgemäß auf die Benutzung mehrere Benutzer ausgerichtet ist, ist die Rechtevergabe von immens großer Bedeutung. Die oberste Instanz ist nun mal ein Verzeichnis namens 'Root' oder das Wurzelverzeichnis. Darunter kommen Unterverzeichnisse und Dateien.
Dateien können entweder ASCII- (Text-) oder Binär-Dateien(Programm-) sein.
Deshalb muss unbedingt vor allen anderen Tätigkeiten ein Planung der Rechte für Verzeichnisse, Gruppen und User erstellt werden.
In einem späteren Teil gehe ich noch auf ACL (Access Control List) ein, wo das Thematik des Verzeichnis wiedermal eine bedeutende Rolle spielen wird. Aber immer eins nach dem anderen... .
1. Verzeichnis - Datei - User/Gruppen
1.2 Datei - Rechte
Da Verzeichnisse wie Dateien behandelt werden, gelten für die 'Normalen'-Dateien die selben Regeln wie für Verzeichnisse, mit Ausnahme des Rechts "Execute" 'x'.
Zur Verdeutlichung führe ich ähnliche Tests durch wie bei den Verzeichnissen.
Zur Einführung und Verdeutlichung setze ich nochmal einen Befehl auf meine Testdatei "tree.txt" ab.
Im Terminal setze ich der Befehl ab:
chmod u=rw
cd test
ls -l tree.txt
- rw- rw- r-- 1 uvr uvr 642801 Dez 29 18:30 tree.txt
- --- --- --- | | | |_ Rechte der Anderen (lesen) | | |_____ Rechte der Gruppe (lesen, schreiben) | |_________ Rechte des Besitzers (lesen, schreiben) |____________ Dateityp (- = Datei, d = Verzeichnis, l = link, ... )
| Rechteinhaber | Zeichen |
|
Besitzer oder "owner, user" |
u |
|
Gruppe oder "group" |
g |
|
alle anderen Benutzer oder "other" |
o |
|
alle Benutzer oder "all" ändert Gruppen u,g,o gleichzeitig |
a |
Die Angaben ob es sich um den Rechteinhaber u,g,o oder a handelt ist nicht zwingend notwendig.
Fehlt die Angabe ist der Rechteinhaber standardmäßig 'all, a' .
Bildungsregel mit chmod Optionen
Ziel Operator Ziel
| u |
| g |
| o |
| a |
——————►
| - |
| + |
| = |
——————►
| r |
| w |
| x |
| s |
Das Ziel 's' ist für den Anwender das Signal, das das SUID (Set-User-ID-Bit) gesetzt wurde.
1. Test <Benutzer, Owner>
im Terminal :
chmode a-rwx tree.txt
ls -l tree.txt
- --- --- --- 1 uvr uvr 642801 Dez 29 18:30 tree.txt
Der Hauptbenutzer und alle anderen habe keine Berechtigung mehr an dieser Datei, nur 'root' hat im Normalfall noch Rechte.
Bei Ubuntu ist der erste angelegte User automatisch Mitglied der Systemverwalter (administratoren), deshalb kann er noch darauf zugreifen und sich die Rechte wieder zuweisen.
Weder die GUI noch der Befehl 'cat' erlaubt einen Zugriff auf die Datei 'tree.txt':
uvr@uvr-HP-Pavilion-17-Notebook-PC:~/test$ cat tree.txt
cat: tree.txt: Keine Berechtigung
2. Test <Benutzer, Owner>
im Terminal :
chmod u+r tree.txt
uvr@uvr-HP-Pavilion-17-Notebook-PC:~/test$ ls -l tree.txt
-r-------- 1 uvr uvr 642801 Dez 29 18:30 tree.txt
cat tree.txt
Der Benutzer kann wieder die Datei lesen.
Die GUI zeigt noch folgendes Phänomen:
Das Icon für diese Textdatei zeigt noch das Symbol 'gesperrt' an, obwohl der Anwender die Leserechte hat.
Eigentlich hätte hier das Sperrsignal nicht mehr auftreten dürfen oder das Sperrsignal hätte ein anderes sein müssen. Z.B ein "Schloß mit -wx" wäre sinnvoll, da ja gerade diese Rechte fehlen, doch würde die Einführung von noch mehr Icons zur Verwirrung des Nichtlesenden geführen oder?
Man ist also wiederum als Administrator besser auf der "Commandline"-Ebene aufgehoben.
3. Test <Benutzer, Other, All>
Diesmal habe ich zum testen einen 2. User 'ub' (Uwe Brentano) angelegt.
Darauf hin habe ich das Verzeichnis 'test' vom Homeverzeichnis des Users 'uvr' nach '/tmp/" im Rootverzeichnis kopiert.
im Terminal :
uvr@uvr-HP-Pavilion-17-Notebook-PC:~$ ls -l
insgesamt 4808
drwx------ 4 uvr uvr 4096 Dez 31 15:32 test --> kopieren nach
uvr@uvr-HP-Pavilion-17-Notebook-PC:/$ ls -l
drwxrwxrwt 7 root root 4096 Jan 2 16:39 tmp
uvr@uvr-HP-Pavilion-17-Notebook-PC:/$ cd /tmp
uvr@uvr-HP-Pavilion-17-Notebook-PC:/tmp$ ls -l
insgesamt 4
drwx------ 4 uvr uvr 4096 Dez 31 15:32 test
cd test
chmod a+r
uvr@uvr-HP-Pavilion-17-Notebook-PC:/tmp/test$ ls -l tree.txt
-r--r--r-- 1 uvr uvr 642801 Dez 29 18:30 tree.txt
Die GUI und die "Commandline" verhalten sich korrekt bis auf das Icon mit dem Schloß.
4. Test <Benutzer, Other>
Test mit Gruppe "alle anderen Benutzer oder "other"
im Terminal:
chmod u-r tree.txt
ls -l
----r--r-- 1 uvr uvr 642801 Dez 29 18:30 tree.txt
Dem Eigentümer habe ich das Recht zu lesen entzogen, der Gruppe und allen anderen Anwendern hingegen dürfen noch lesen. Wie ist nun die Reaktion des System?
Der Benutzer darf die Datei nicht öffnen, obwohl die Gruppe und alle anderen Anwendern das Recht eingeräumt ist.
Das Verhalten ist korrekt, denn obwohl der Anwender "uvr" Mietglied der Gruppe "uvr" und allen Anderen ist, hat der Ausschluß des Anwenders "uvr" vom Leserecht höchste Priorität.
Das Recht "Lesen verboten" ist also ausschließend für alle anderen Rechte!
Da das Verbot ja nur für den Anwender "uvr" gilt, müsste eigentlich der Anwender "ub" auf die Datei "tree.txt" zu greifen dürfen. Gesagt, getan!
Ich wechsel kurzer Hand der Anwender und melde mich als "ub" an.
Leider habe ich etwas vergessen:
Das Verzeichnis /tmp/test hat folgende Rechte:
drwx------ 4 uvr uvr 4096 Dez 31 15:32 test
Da dem User die entsprechenden Rechte fehlen muss ich als Anwender "uvr" dem Anwender "ub" noch das Recht einräumen in das Verzeichnis "test" zu wechseln:
chmod o+x test
ls -l
drwx-----x 4 uvr uvr 4096 Dez 31 15:32 test
cd test
ub@uvr-HP-Pavilion-17-Notebook-PC:/$ ls -l
ls: Öffnen von Verzeichnis . nicht möglich: Keine Berechtigung
Dem Anwender "ub" ist es jetzt erlaubt in das Verzeichnis "test" zu wechseln, kann sich aber den Inhalt des Verzeichnis auf Grund mangelnder Leserechte nicht anzeigen lassen.
Der Benutzer "uvr" (Owner) muß noch das Recht "Lesen" (r) vergeben:
uvr@uvr-HP-Pavilion-17-Notebook-PC:/tmp$ chmod o+r test
uvr@uvr-HP-Pavilion-17-Notebook-PC:/tmp$ ls -l
drwx---r-x 4 uvr uvr 4096 Dez 31 15:32 test
Der Anwender "ub" kann nun in das Verzeichnis "test" wechseln und sich den Inhalt des Verzeichnisses anzeigen lassen:
ub@uvr-HP-Pavilion-17-Notebook-PC:/tmp/test$ ls -l
-r--rw---- 1 uvr uvr 642801 Dez 29 18:30 tree.txt
Da der Anwender "ub" nicht Mitglied der Gruppe "uvr" ist fehlen ihm die Rechte auf die Datei "tree.txt" zu zugreifen.
Das Thema der fehlenden Gruppenrechte an der Gruppe "uvr" kann erst mit ACL gelöst werden.Aber das ist ein anderes Thema!
Wir können das Problem nur umgehen indem wir der Gruppe "alle anderen Anwender"
"other o" die entsprechenden Rechte einräumen.
uvr@uvr-HP-Pavilion-17-Notebook-PC:/tmp/test$ chmod o+r tree.txt
uvr@uvr-HP-Pavilion-17-Notebook-PC:/tmp/test$ ls -l
-r--rw-r-- 1 uvr uvr 642801 Dez 29 18:30 tree.txt
Jetzt erst kann der Anwender (ub) die Datei "tree.txt" lesen.
Dies zeigt sich auch am Icon der Datei "tree.txt", das Schloß ist verschwunden!
Dem Anwender oder Owner "uvr" ist das Lesen der Datei immer noch erlaubt, obwohl ein Schloß am Icon angezeigt wird.
Zusammenfassung:
Man kann die Gruppe "alle anderen Anwender oder 'other' " auch mit der Windows-Gruppe 'jeder' vergleichen, wo bei hier ein der Begriff 'other' besser geeignet.
Die Gruppe 'other' impliziert nämlich, das es sich um die Rechtevergabe für alle übrigen Anwender außer dem Eigentümer (owner, 'user') handelt.
Wird eine Datei von einem Anwender erstellt, so erhält diese Datei die Rechte der Gruppe "group 'g' " die unter Debian/GNU gleich dem Namen des Anwender ist und dieselben Rechte vom Besitzer (owner) erhält (erbt).
Jeder Benutzer gehört mindestens eine Gruppe an, die auch Primäre-Gruppe (/etc/passwd) genannt wird. Der User erhält gleichzeitig auch eine Mitgliedschaft in einer Sekundären-Gruppe, die wiederum seinen Name trägt.
Weiter über Rechte und Gruppen gibt es im Teil 3 wo auf Gruppen und deren Verwaltung mehr eingegangen wird.