Linux-Benutzergruppen und Dateiberechtigungen

Einführung

Linux ist ein Mehrbenutzer-Betriebssystem. Jeder Prozess und jede Datei gehört einem Benutzer. Jeder Benutzer hat außerdem eine primäre Gruppe und kann zusätzliche Gruppenmitgliedschaften besitzen. Identität, Eigentümer und Berechtigungsbits bestimmen gemeinsam, wer eine Ressource lesen, ändern, ausführen oder betreten darf.

In diesem Laborkurs richten Sie mit eigenen Übungskonten eine kleine Teamumgebung ein. Sie erstellen einen Benutzer, verwalten Gruppenmitgliedschaften, sichern eine Datei, prüfen eine Kontosperre, steuern Standardberechtigungen mit umask und konfigurieren Verzeichnisse mit Sticky Bit und setgid. Alle Arbeiten bleiben in der Laborumgebung und verändern den standardmäßigen labex-Anmeldepfad nicht.

Identitäten prüfen und einen Übungsbenutzer erstellen

In diesem Schritt prüfen Sie Ihre aktuelle Identität und erstellen ein separates Konto für Übungen zu Dateiberechtigungen. Linux identifiziert einen Benutzer mit einem Benutzernamen und einer numerischen Benutzer-ID (UID). Außerdem werden eine primäre Gruppen-ID (GID) und zusätzliche Gruppenmitgliedschaften gespeichert.

Prüfen Sie zuerst die Identität der aktuellen Shell:

whoami

Die Ausgabe sollte labex lauten. Zeigen Sie nun die UID, die primäre Gruppe und die zusätzlichen Gruppen dieses Kontos an:

id

Die genauen numerischen IDs können abweichen. Die Ausgabe kennzeichnet sie jedoch mit uid, gid und groups.

Das Erstellen eines Kontos ändert Systemdateien und erfordert daher administrative Berechtigungen. sudo bedeutet „superuser do“: Nach einer Prüfung, ob das aktuelle Konto dazu berechtigt ist, führt sudo den folgenden Befehl mit erweiterten Rechten aus. Verwenden Sie sudo nur für den Befehl, der administrative Rechte benötigt, und lesen Sie den vollständigen Befehl, bevor Sie die Eingabetaste drücken.

Der folgende Befehl useradd verwendet drei Optionen:

• -m erstellt das Home-Verzeichnis.
• -U erstellt eine primäre Gruppe mit demselben Namen.
• -s /bin/bash legt Bash als Login-Shell des Kontos fest.

Erstellen Sie einen Übungsbenutzer namens jack:

sudo useradd -m -U -s /bin/bash jack

Prüfen Sie das neue Konto und sein Home-Verzeichnis:

id jack

ls -ld /home/jack

Die Ausgabe von id sollte jack sowohl als Benutzer als auch als primäre Gruppe anzeigen. Die Verzeichnisauflistung sollte zeigen, dass /home/jack existiert und jack:jack gehört.

Zusätzliche Gruppen verwalten

In diesem Schritt erstellen Sie eine Teamgruppe und nehmen Benutzer in zusätzliche Gruppen auf. Die primäre Gruppe eines Benutzers wird normalerweise zum Gruppeneigentümer neu erstellter Dateien. Zusätzliche Gruppen gewähren Zugriff auf weitere gemeinsam genutzte Ressourcen.

Erstellen Sie eine Gruppe namens developers:

sudo groupadd developers

Die Optionen usermod -aG bedeuten „zusätzliche Gruppenmitgliedschaften ergänzen“. Die Option -a ist wichtig: Ohne sie kann -G bereits vorhandene zusätzliche Gruppenmitgliedschaften ersetzen. Nehmen Sie jack in die Gruppen developers und sudo auf:

sudo usermod -aG developers,sudo jack

Nehmen Sie außerdem labex als Mitglied in developers auf. Die aktuelle Shell erhält die neue Gruppenidentität nicht sofort. Sie aktualisieren sie sicher im letzten Schritt.

sudo usermod -aG developers labex

Prüfen Sie beide Konten:

groups jack

groups labex

Die erste Ausgabe sollte jack, developers und sudo enthalten. Die zweite Ausgabe sollte developers enthalten. Die Mitgliedschaft in sudo ermöglicht es einem authentifizierten Konto, erweiterte Berechtigungen anzufordern. Vergeben Sie diese Mitgliedschaft daher nur an vertrauenswürdige Administratoren.

Dateieigentümer und Berechtigungen steuern

In diesem Schritt sichern Sie einen Teambericht mit einem bestimmten Eigentümer, einer bestimmten Gruppe und einem bestimmten Berechtigungsmodus. Eine lange Dateiauflistung zeigt zuerst den Dateityp und danach drei Berechtigungsgruppen für Eigentümer, Gruppe und andere Benutzer.

Erstellen Sie im Projektverzeichnis einen leeren Bericht:

touch /home/labex/project/secure-report.txt

Ändern Sie Eigentümer und Gruppe mit der Schreibweise user:group von chown:

sudo chown jack:developers /home/labex/project/secure-report.txt

Setzen Sie den Modus 640:

sudo chmod 640 /home/labex/project/secure-report.txt

In der numerischen Schreibweise steht 4 für Lesen, 2 für Schreiben und 1 für Ausführen. Daher gilt:

• Eigentümer 6 bedeutet Lesen und Schreiben (4 + 2).
• Gruppe 4 bedeutet nur Lesen.
• Andere Benutzer 0 bedeutet kein Zugriff.

Prüfen Sie das Ergebnis:

ls -l /home/labex/project/secure-report.txt

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/secure-report.txt

Die stabilen Felder der Ausgabe von stat sollten owner=jack group=developers mode=640 melden.

Eine Kontosperre prüfen und ändern

In diesem Schritt üben Sie, ein eigenes Konto vorübergehend zu sperren und wieder zu entsperren. Linux speichert Passwort-Hashes und den Kontostatus in /etc/shadow. Ein führendes ! im Passwortfeld kennzeichnet die Passwortauthentifizierung als gesperrt.

Bei der Einrichtung wurde ein Übungskonto namens contractor erstellt. Geben Sie nur das erste Zeichen seines Passwortfelds aus, damit der Hash selbst niemals angezeigt wird. Lesen Sie die Pipeline von links nach rechts: getent shadow contractor ruft den Shadow-Eintrag des Kontos ab; das erste cut verwendet : als Trennzeichen und wählt Feld 2 aus; das zweite cut behält Zeichen 1 dieses Felds:

sudo getent shadow contractor | cut -d: -f2 | cut -c1

Das erste Zeichen sollte normalerweise $ sein. Es steht am Anfang eines modernen Passwort-Hashformats. Sperren Sie das Konto mit usermod -L:

sudo usermod -L contractor

Prüfen Sie das erste Zeichen erneut:

sudo getent shadow contractor | cut -d: -f2 | cut -c1

Nun sollte ! ausgegeben werden. Entsperren Sie das Konto mit usermod -U und bestätigen Sie, dass ! verschwunden ist:

sudo usermod -U contractor

sudo getent shadow contractor | cut -d: -f2 | cut -c1

In diesem Szenario hat der Auftragnehmer das Team nun verlassen. Sperren Sie das Konto ein letztes Mal, während Sie seine Dateien erhalten:

sudo usermod -L contractor

Das Sperren der Passwortauthentifizierung löscht weder das Konto noch dessen Home-Verzeichnis und beendet nicht unbedingt bereits bestehende Sitzungen. Es unterscheidet sich vom Löschen eines Benutzers und ist nützlich, wenn Dateien zur späteren Prüfung erhalten bleiben müssen.

Standardberechtigungen mit Umask steuern

In diesem Schritt verwenden Sie umask, um die Berechtigungsbits zu steuern, die beim Erstellen neuer Dateien und Verzeichnisse durch die Shell entfernt werden. Programme beginnen normalerweise mit dem maximalen Modus 666 für reguläre Dateien und 777 für Verzeichnisse. Eine Maske von 027 entfernt die Schreibberechtigung für die Gruppe sowie alle Berechtigungen für andere Benutzer.

Erstellen Sie einen Arbeitsbereich für das Experiment:

mkdir -p /home/labex/project/umask-demo

Speichern Sie die aktuelle Maske, damit Sie sie später wiederherstellen können. Die Syntax $(command) wird Command Substitution genannt: Die Shell führt den Befehl in den Klammern aus und ersetzt den gesamten Ausdruck durch dessen Ausgabe. Die Zuweisung speichert dieses Ergebnis in original_umask. Wie bei anderen Shell-Zuweisungen dürfen sich um = keine Leerzeichen befinden.

original_umask=$(umask)

Setzen Sie die Maske 027 und erstellen Sie anschließend eine Datei und ein Verzeichnis:

umask 027

touch /home/labex/project/umask-demo/private-note.txt

mkdir /home/labex/project/umask-demo/private-dir

Prüfen Sie die resultierenden numerischen Modi:

stat -c '%a %n' /home/labex/project/umask-demo/private-note.txt /home/labex/project/umask-demo/private-dir

Die Datei sollte den Modus 640 und das Verzeichnis den Modus 750 haben. Dateien erhalten nicht automatisch Ausführungsbits. Stellen Sie die ursprüngliche Maske der Shell wieder her:

umask "$original_umask"

Eine Änderung von umask wirkt sich auf danach erstellte Objekte aus. Die Berechtigungen bereits vorhandener Objekte werden dadurch nicht geändert.

Ein gemeinsam genutztes Verzeichnis mit dem Sticky Bit schützen

In diesem Schritt konfigurieren Sie eine öffentliche Ablage, in der alle Benutzer Dateien erstellen, aber keine Dateien anderer Benutzer löschen dürfen. Der normale Modus 777 gewährt allen Benutzern vollständigen Zugriff auf das Verzeichnis. Das Sticky Bit ändert die Regeln für das Löschen innerhalb des Verzeichnisses.

Erstellen Sie das gemeinsam genutzte Verzeichnis und setzen Sie den Modus 1777. Die führende 1 aktiviert das Sticky Bit.

mkdir /tmp/shared-dropbox

chmod 1777 /tmp/shared-dropbox

Verwenden Sie sudo -u, um jeweils eine Datei als jedes Übungskonto zu erstellen:

sudo -u jack touch /tmp/shared-dropbox/jack-note.txt

sudo -u contractor touch /tmp/shared-dropbox/contractor-note.txt

Versuchen Sie nun, als jack die Datei des Auftragnehmers zu löschen:

sudo -u jack rm /tmp/shared-dropbox/contractor-note.txt

Da jack keine Schreibberechtigung für die Datei des Auftragnehmers hat, fragt ein interaktives Terminal möglicherweise zunächst, ob die schreibgeschützte Datei entfernt werden soll:

rm: remove write-protected regular empty file '/tmp/shared-dropbox/contractor-note.txt'?

Wenn diese Frage erscheint, geben Sie y ein und drücken Sie Enter. Damit bestätigen Sie den Löschversuch; Sie erhalten dadurch keine Berechtigung, das Sticky Bit zu umgehen. In einer nicht interaktiven Umgebung kann die Bestätigung entfallen.

Der Löschversuch muss mit Operation not permitted fehlschlagen, und die Datei des Auftragnehmers muss erhalten bleiben. Dieser Fehler ist beabsichtigt und bedeutet nicht, dass der Schritt fehlerhaft ist. Prüfen Sie anschließend das Verzeichnis:

ls -ld /tmp/shared-dropbox

Die Berechtigungen sollten mit einem kleingeschriebenen t enden, zum Beispiel drwxrwxrwt. Das kleingeschriebene t bedeutet, dass sowohl das Sticky Bit als auch die Ausführungsberechtigung für andere Benutzer gesetzt sind. Ein großgeschriebenes T würde bedeuten, dass das Sticky Bit gesetzt ist, die zugehörige Ausführungsberechtigung jedoch fehlt.

Ein Teamverzeichnis mit Setgid konfigurieren

In diesem Schritt richten Sie ein privates Verzeichnis für die Zusammenarbeit ein. Bei einem Verzeichnis bewirkt setgid, dass neu erstellte untergeordnete Objekte die Gruppe des Verzeichnisses statt der primären Gruppe des Erstellers erben. Dadurch bleiben Teamdateien einer gemeinsamen Gruppe zugeordnet.

Prüfen Sie zuerst, ob der Benutzer und die Gruppe aus den Schritten 1 und 2 vorhanden sind. id jack zeigt die Identität des Übungsbenutzers an; getent group developers sucht die benannte Gruppe in der Kontodatenbank des Systems:

id jack

getent group developers

Der erste Befehl muss jack identifizieren. Der zweite muss einen Gruppeneintrag anzeigen, der mit developers: beginnt und jack sowie labex enthält. Die numerischen IDs können variieren. Wenn eine Abfrage fehlschlägt oder eine Mitgliedschaft fehlt, kehren Sie zu den Schritten 1 und 2 zurück und führen Sie die fehlenden Aktionen aus, bevor Sie fortfahren. Ein Fehler von chown wie invalid user: 'jack:developers' bedeutet, dass der benannte Benutzer oder die Gruppe nicht aufgelöst werden kann; geänderte Verzeichnisberechtigungen erstellen diese nicht.

Erstellen Sie das Verzeichnis:

mkdir /home/labex/project/team-share

Machen Sie jack zum Eigentümer und developers zum Gruppeneigentümer:

sudo chown jack:developers /home/labex/project/team-share

Setzen Sie den Modus 2770. Die führende 2 aktiviert setgid; 770 gewährt dem Eigentümer und der Gruppe vollständigen Zugriff und verweigert den Zugriff für andere Benutzer.

sudo chmod 2770 /home/labex/project/team-share

Prüfen Sie das Ergebnis:

ls -ld /home/labex/project/team-share

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/team-share

Die lange Auflistung sollte an der Position für die Gruppenausführungsberechtigung ein s zeigen, zum Beispiel drwxrws---. Ein kleingeschriebenes s bedeutet, dass sowohl setgid als auch die Gruppenausführungsberechtigung aktiv sind. Ein großgeschriebenes S würde bedeuten, dass setgid gesetzt ist, die Gruppenausführungsberechtigung jedoch fehlt.

Setuid wird durch ein s an der Position für die Ausführungsberechtigung des Eigentümers dargestellt und kommt häufig bei sorgfältig kontrollierten Systemprogrammen vor. Erkennen Sie dieses Bit beim Lesen von Berechtigungen, aber setzen Sie es nicht für beliebige Programme.

Gruppenmitgliedschaft aktualisieren und Vererbung prüfen

In diesem Schritt aktivieren Sie die Mitgliedschaft in developers in einer untergeordneten Shell und weisen nach, dass setgid die Gruppe einer neuen Datei festlegt. Wenn ein Benutzer zu /etc/group hinzugefügt wird, werden die zusätzlichen Gruppen einer bereits laufenden Shell nicht automatisch neu gesetzt.

Prüfen Sie vor dem Gruppenwechsel, ob Sie als labex arbeiten und ob dessen Mitgliedschaft in Schritt 2 in der Kontodatenbank eingetragen wurde:

whoami

id labex

Die erste Ausgabe muss labex sein, und die zweite muss developers in der Gruppenliste enthalten. Anders als id ohne Argument, das den aktuellen Prozess beschreibt, fragt id labex die konfigurierten Mitgliedschaften des benannten Kontos ab. Falls developers fehlt, kehren Sie zu Schritt 2 zurück, führen Sie sudo usermod -aG developers labex aus und wiederholen Sie diese Prüfung. Fahren Sie bei fehlender Mitgliedschaft nicht fort.

Starten Sie im selben eigenständigen Tab Terminal eine untergeordnete Shell mit developers als aktiver Gruppe:

newgrp developers

Wenn labex als Mitglied von developers eingetragen ist, sollte kein Gruppenpasswort abgefragt werden. Wenn Password: erscheint, brechen Sie mit Ctrl+C ab, prüfen Sie erneut whoami und id labex und ergänzen Sie die fehlende Mitgliedschaft aus Schritt 2, bevor Sie es erneut versuchen. Geben Sie weder Ihr Passwort für die LabEx-Website ein noch setzen Sie ein Gruppenpasswort.

Die Eingabeaufforderung wird möglicherweise aktualisiert. Sie sind weiterhin der Benutzer labex, aber die untergeordnete Shell verwendet nun developers als effektive Gruppe. Bestätigen Sie beide Identitäten:

id

uid muss weiterhin labex identifizieren, während gid nun developers identifizieren muss.

Erstellen Sie eine Datei im setgid-Verzeichnis:

touch /home/labex/project/team-share/labex-note.txt

Prüfen Sie die neue Datei:

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/team-share/labex-note.txt

Der Eigentümer sollte labex sein, während die Gruppe developers sein sollte. setgid vererbt den Gruppeneigentümer. Die Lese- und Schreibbits der Datei hängen weiterhin vom erstellenden Prozess und dessen umask ab.

Beenden Sie die untergeordnete Shell und kehren Sie zur ursprünglichen Terminalsitzung zurück:

exit

Die Datei bleibt erhalten, nachdem die untergeordnete Shell geschlossen wurde.

Zusammenfassung

Sie haben das grundlegende Identitäts- und Zugriffsmodell von Linux geübt. Sie haben einen Benutzer und eine Teamgruppe erstellt, zusätzliche Gruppenmitgliedschaften verwaltet, Eigentümer zugewiesen und numerische Berechtigungsmodi in praktische Zugriffsregeln übersetzt. Außerdem haben Sie eine Kontosperre geprüft, ohne den Passwort-Hash offenzulegen.

Anschließend haben Sie sich mit speziellen Berechtigungen beschäftigt: umask steuerte die Standardberechtigungen, das Sticky Bit schützte Dateien in einem öffentlichen Verzeichnis, und setgid bewahrte den Gruppeneigentümer des Teams in einem privaten Verzeichnis für die Zusammenarbeit. Zum Schluss haben Sie mit newgrp die Gruppenmitgliedschaft aktualisiert und die vererbte Gruppe anhand einer echten Datei überprüft.