Linux: Benutzer, Gruppen und Zugriffsrechte

Jeder Befehl läuft mit einer Identität. Anhand dieser Identität entscheidet Linux, welche Dateien der Befehl öffnen und welche Einstellungen er ändern darf. Ein Benutzerkonto kann für eine Person oder einen im Hintergrund laufenden Dienst stehen.

Die Nummer hinter dem Namen

Der Kernel identifiziert ein Konto anhand seiner Benutzer-ID (UID). Namen wie alice machen die Nummer leichter erkennbar, aber die Rechte richten sich nach der Nummer. Das root-Konto hat die UID 0 und sein Home-Verzeichnis ist /root. Ein Konto mit einem anderen Namen und UID 0 hat dieselben Superuser-Rechte.

Ein reguläres Benutzerkonto ist das Alltagskonto einer Person. Auf den meisten Distributionen beginnen reguläre UIDs bei 1000; UID_MIN in /etc/login.defs legt diese Schranke fest. Ein regulärer Benutzer kann eigene Dateien und alle anderen Dateien ändern, die die Zugriffsrechte erlauben. Zum Ändern geschützter Systemeinstellungen sind erhöhte Rechte nötig.

Ein Systemkonto gibt einem Dienst eine eigene eingeschränkte Identität. Die meisten haben UIDs unter 1000 und eine Shell wie /usr/sbin/nologin. Das Sonderkonto nobody hat häufig UID 65534, sodass der Nummernbereich allein nicht jedes Dienstkonto erkennen lässt. Debian und Ubuntu verwenden www-data für Webdienste; ein SSH-Dienst kann sshd verwenden.

Deine aktuelle Identität ablesen

Führe whoami für deinen Benutzernamen oder id für die Nummern und Gruppen aus. Zum Beispiel:

uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),1005(developers)

Lies die Ausgabe in drei Teilen. Alices UID ist 1001. Ihre primäre Gruppe ist alice, GID 1001. Ihre Gruppenliste enthält auch sudo und developers. Sie ist eine reguläre Benutzerin, nicht root: Die Gruppe sudo kann Befehle mit erhöhten Rechten erlauben, aber ihre aktuelle Shell läuft weiterhin als Alice.

Viele Shells zeigen # für root und $ für einen regulären Benutzer an. Eine Eingabeaufforderung kann angepasst werden, prüfe daher id, wenn die Identität wichtig ist. Das erste bei der Installation angelegte Konto ist häufig ein reguläres Konto mit sudo-Zugriff, auch unter Ubuntu; durch das Anlegen als erstes Konto wird es nicht zu root.

Anmeldesitzungen prüfen

Diese Befehle beantworten eine andere Frage als whoami: Sie zeigen Sitzungen und nicht nur die Identität deiner Shell. Debian 13 ist eines der Systeme, die wtmpdb für ihren Verlauf verwenden.

Getrennte Identitäten unterstützen das Prinzip der geringsten Rechte, Zurechenbarkeit und Isolation. Ein Webdienst kann die Dateien lesen, die er bereitstellt, ohne Zugriff auf die privaten Dokumente jedes Benutzers zu erhalten. Protokolle können zeigen, welches Konto gehandelt hat. Wird der Dienst kompromittiert, beginnt der Angriff mit den Rechten dieses Dienstkontos. Root kann gewöhnliche Beschränkungen beim Lesen und Schreiben von Dateien umgehen, daher ist ein zweites Konto mit UID 0 ein ernstes Sicherheitsrisiko.

Eine Datei mit einem Team zu teilen ist einfacher, wenn das Team eine Gruppe hat. Ordne die Datei dieser Gruppe zu, gib der Gruppe die benötigten Rechte und verwalte die Mitgliedschaft, wenn Personen hinzukommen oder das Team verlassen.

Eine primäre Gruppe, weitere Mitgliedschaften

Eine Gruppe hat einen Namen und eine numerische Gruppen-ID (GID). Jeder Benutzer hat eine primäre Gruppe, die als GID in /etc/passwd gespeichert ist. Eine neue Datei übernimmt normalerweise die primäre Gruppe des erstellenden Prozesses. Später lernst du mit einem SGID-Verzeichnis eine weitere Regel für die Gruppenzuordnung neuer Dateien kennen.

Benutzer können auch mehreren zusätzlichen Gruppen angehören. Diese Mitgliedschaften ergänzen die Gruppenidentitäten ihrer Prozesse; der Benutzer muss nicht jedes Mal die primäre Gruppe wechseln, wenn er die Datei eines anderen Teams öffnet. Sowohl primäre als auch zusätzliche Gruppen zählen, wenn Linux prüft, ob der Benutzer zur Gruppe einer Datei gehört.

Die meisten Distributionen erstellen für jeden regulären Benutzer eine private Benutzergruppe. Alice kann den Benutzernamen alice, UID 1001, die primäre Gruppe alice und GID 1001 haben. Benutzer- und Gruppenidentität bleiben getrennt, auch wenn Namen und Nummern übereinstimmen. Eine Datei, die Alices privater Gruppe zugeordnet ist, wird nicht mit dem ganzen Team geteilt.

Eine Mitgliedschaft untersuchen

Verwende groups für deine eigenen Gruppennamen. groups bob und id bob fragen Bobs Mitgliedschaften ab; id -Gn gibt die Gruppennamen des aktuellen Prozesses ohne Nummern aus. Eine Gruppenabfrage könnte Folgendes zeigen:

getent group developers
developers:x:1005:alice,bob

Die Gruppe heißt developers, ihre GID ist 1005 und Alice und Bob sind als zusätzliche Mitglieder aufgeführt. Ein Konto mit der primären GID 1005 gehört ebenfalls zur Gruppe, auch wenn sein Name in dieser letzten Liste fehlt. Um die vollständige Gruppenmitgliedschaft einer Person zu prüfen, verwende id mit ihrem Namen, statt dich allein auf diese Liste zu verlassen.

Die Rechte einer Gruppe anwenden

Angenommen, plan.txt gehört bob:developers und hat den Modus rw-r-----. Alice ist nicht Bob, gehört aber zu developers. Daher gilt für sie das mittlere Rechtetripel r--: Sie kann den Plan lesen, aber seinen Inhalt nicht ändern. Chen ist weder der Eigentümer noch gehört er zur Gruppe, daher gilt für ihn das letzte Tripel ---.

Die Änderung der einer Datei zugeordneten Gruppe schafft für sich genommen keine Rechte. Lautet das Gruppentripel ---, erhalten Mitglieder über diese Klasse weiterhin keinen Zugriff. Die Gruppenzuordnung bestimmt das Team; die Rechtebits legen fest, was das Team tun kann.

Gruppen mit weitreichenden Rechten erkennen

Einige Mitgliedschaften gewähren deutlich mehr als Zugriff auf ein Projektverzeichnis. Debian und Ubuntu berechtigen gewöhnlich die Gruppe sudo zu administrativen Befehlen; Fedora und Red Hat Enterprise Linux verwenden gewöhnlich wheel. Unter Debian und Ubuntu erlaubt adm den Zugriff auf viele Systemprotokolle. Die Gruppe docker steuert den Docker-Dienst und bietet praktisch Kontrolle auf root-Ebene.

Bevor du jemanden zu einer Gruppe hinzufügst, ermittle, worauf sie zugreifen kann. Eine Projektgruppe kann eine eng begrenzte Möglichkeit sein, Arbeit zu teilen, während eine administrative Gruppe die Kontrolle über den ganzen Rechner gewähren kann.

Linux hält öffentliche Kontodaten von Passwortdaten getrennt. Wenn du die Reihenfolge der Felder liest, kannst du die Identität, die Anmeldung und die Passwortrichtlinie eines Kontos erklären, ohne die Dateien von Hand zu ändern.

Einen Kontoeintrag lesen

/etc/passwd hat sieben durch Doppelpunkte getrennte Felder:

name:password:UID:GID:comment:home:shell
alice:x:1001:1001:Alice Moreau:/home/alice:/bin/bash

Alices UID und primäre GID sind beide 1001. Der Kommentar, auch GECOS-Feld genannt, enthält ihren vollständigen Namen. Ihr Home-Verzeichnis ist /home/alice und ihre Login-Shell ist Bash. Das x verweist auf Passwortdaten in /etc/shadow; es bedeutet nicht, dass ihr Passwort leer ist.

Gewöhnliche Benutzer können /etc/passwd lesen, normalerweise mit Modus 644. Programme brauchen die öffentlichen Angaben, um gespeicherte UIDs in Namen aufzulösen. Da Passworthashes in einer getrennten geschützten Datei liegen, kann nicht jeder lokale Benutzer sie lesen.

Passwortdaten lesen

/etc/shadow hat neun Felder: Name, Passworthash, Tag der letzten Änderung, Mindestalter, Höchstalter, Warntage, Inaktivitätstage, Kontoablauftag und ein reserviertes Feld. Root kann die Datei lesen; manche Systeme gewähren auch der Gruppe shadow Zugriff.

Ein Passworthash ist ein Einwegergebnis, keine umkehrbare Verschlüsselung. Bei der Anmeldung wendet das System das gespeicherte Verfahren und den Salt auf das eingegebene Passwort an und vergleicht das Ergebnis mit dem gespeicherten Hash. Ein zufälliger Salt sorgt für unterschiedliche Hashes, selbst wenn zwei Benutzer dasselbe Passwort wählen. SHA-512-crypt-Einträge verwenden $6$salt$hash, optional mit einem Feld rounds=N; yescrypt verwendet $y$parameters$salt$hash.

Ein führendes ! sperrt das Passwort und behält den Hash bei. Ein Feld, das nur !, !! oder * enthält, hat kein verwendbares Passwort. Andere Anmeldeverfahren wie SSH-Schlüssel können bei gesperrtem Passwort weiterhin funktionieren.

Die Daten ermitteln

Betrachte diesen verkürzten Hash-Eintrag:

alice:$y$j9T$...:20514:0:90:7:::

Die Datumswerte zählen die Tage seit dem 1. Januar 1970, UTC. Tag 20514 ist der 2. März 2026. Ein Mindestalter von 0 erlaubt eine sofortige Passwortänderung; ein Höchstalter von 90 bedeutet den Ablauf am 31. Mai 2026. Die Warnfrist von sieben Tagen beginnt am 24. Mai. Leere Felder für Inaktivität und Kontoablauf legen keine dieser Beschränkungen fest. Der Wert 0 für die letzte Änderung erzwingt eine Änderung bei der nächsten Anmeldung; ein Höchstalter von 99999 entspricht praktisch einer sehr langen Passwortlaufzeit. Passwortablauf und Kontoablauf stehen in getrennten Feldern.

Gruppeneinträge sicher lesen

/etc/group verwendet name:password:GID:members. In developers:x:1005:alice,bob listet das letzte Feld zusätzliche Mitglieder auf. Primäre Mitglieder werden über die GID in ihren passwd-Einträgen gefunden. Das geschützte /etc/gshadow speichert Gruppenpasswörter und Daten zu Gruppenadministratoren.

Verwende getent passwd alice oder getent group developers für Abfragen. getent berücksichtigt neben lokalen Dateien auch konfigurierte Kontoquellen. cut -d: -f1,3 /etc/passwd zeigt lokale Namen und UIDs. Ändere Einträge mit Kontobefehlen wie usermod und passwd; ist eine direkte Bearbeitung unvermeidbar, sperren vipw und vigr die Dateien währenddessen.

Administrative Aufgaben brauchen mehr Zugriff als alltägliche Arbeiten. Lass deine gewöhnliche Shell unter deinem eigenen Konto laufen und erhöhe die Rechte für die Aktion, die sie benötigt. Dateien, die ein Befehl mit erhöhten Rechten erstellt, können root gehören, auch wenn sie in deinem Home-Verzeichnis liegen.

Zwischen sudo und su wählen

Eine Login-Shell lädt die Anmeldeumgebung des Zielbenutzers einschließlich Home-Verzeichnis und Startdateien. Verwende exit, um eine mit su gestartete Shell zu verlassen. sudo -i öffnet eine root-Login-Shell; sudo -s öffnet eine root-Shell. Das ist für eine Reihe zusammengehöriger administrativer Aufgaben nützlich, aber jeder Befehl in dieser Shell hat erhöhte Rechte, bis du sie verlässt.

Sudo prüft vor der Ausführung des Befehls seine Richtlinie und protokolliert den Versuch. Protokolle können im systemd-Journal, in /var/log/auth.log auf Systemen der Debian-Familie oder in /var/log/secure auf Systemen der Red-Hat-Familie landen. sudo -l zeigt die Befehle, die dein Konto ausführen darf. Die Erlaubnis zur Verwendung von sudo ergibt sich aus der Richtlinie, nicht aus der Kenntnis des Passworts einer anderen Person.

Die Authentifizierung verstehen

Standardmäßig fragt sudo nach dem Passwort des aufrufenden Benutzers, nicht nach dem von root. Die Richtlinie kann dieses Verhalten ändern. Der Authentifizierungszeitstempel der Upstream-Version von sudo gilt standardmäßig fünf Minuten; Distributionen können einen anderen Wert einstellen, etwa 15 Minuten. Der Zeitstempel gilt normalerweise innerhalb dieses Terminals. Führe sudo -k aus, um ihn nach Abschluss ungültig zu machen.

Ubuntu startet normalerweise ohne verwendbares root-Passwort und nimmt den Installationsbenutzer in sudo auf. Fedora und Systeme der Red-Hat-Familie verwenden gewöhnlich wheel. Bei einem abgelehnten Versuch kann gemeldet werden, dass der Benutzer nicht in der sudoers-Datei steht; der Versuch wird protokolliert.

Den Schreibvorgang unter sudo ausführen

Dieser Befehl schlägt fehl, wenn dein gewöhnliches Konto nicht in /etc/hosts schreiben darf:

sudo echo "192.0.2.10 test.local" >> /etc/hosts

Deine aktuelle Shell öffnet die Datei für >>, bevor sudo läuft. Nur echo erhält root-Rechte und echo ist nicht das Programm, das die Zieldatei öffnet. Übertrage die Schreibaufgabe einem Prozess mit erhöhten Rechten:

echo "192.0.2.10 test.local" | sudo tee -a /etc/hosts

Hier öffnet tee die geschützte Datei als root. Seine Option -a hängt an; ohne diese Option würde der Inhalt der Datei ersetzt. Für eine interaktive Bearbeitung führt sudoedit /etc/hosts, auch sudo -e /etc/hosts geschrieben, deinen Editor unter deinem Benutzerkonto aus und übernimmt die Aktualisierung der geschützten Datei.

Arbeit im Eigentum von root erkennen

Prüfe nach sudo mkdir ~/project das Ergebnis mit ls -ld ~/project. Das Verzeichnis liegt in deinem Home-Verzeichnis, wurde aber von root erstellt. Seine Eigentümerrechte gelten daher für root, während dein Konto möglicherweise nur Lese- und Ausführungsrechte hat. Stelle mit sudo chown alice: ~/project den vorgesehenen Eigentümer wieder her, wenn das Projekt Alice gehört. Der abschließende Doppelpunkt wählt auch Alices Anmeldegruppe. Anschließend können gewöhnliche Bearbeitungen und Dateierstellungen unter Alices Konto erfolgen.

Eine sudo-Regel legt fest, wer eine Aktion auf welchem Host und unter welcher Identität ausführen darf. Erlaubst du einem Team eine administrative Aktion, kann das seinen Bedarf decken, ohne uneingeschränkte Kontrolle über den Rechner zu gewähren.

Die Teile einer Regel lesen

Das Grundmuster lautet who where = (as_whom) what. Zum Beispiel:

alice ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL

Die erste Regel erlaubt Alice, jeden Befehl auf jedem Host als jeder Benutzer und jede Gruppe auszuführen. Die zweite gewährt der Gruppe sudo dieselben Rechte; % kennzeichnet einen Gruppennamen. Eine übliche Regel der Red-Hat-Familie ist %wheel ALL=(ALL) ALL.

Um Alice über eine bestehende Distributionsregel zur vollberechtigten Administratorin zu machen, führe unter Debian oder Ubuntu sudo usermod -aG sudo alice aus oder verwende unter Fedora und verwandten Systemen wheel. Alice muss sich neu anmelden, damit die Mitgliedschaft in ihrer Sitzung wirksam wird. Das -a ist wichtig: Ohne es ersetzt -G ihre anderen zusätzlichen Gruppen.

Die Richtlinie bearbeiten und prüfen

Die Hauptdatei ist /etc/sudoers; zusätzliche Regeln können in /etc/sudoers.d/ liegen. Verwende sudo visudo oder bearbeite gezielt eine Datei:

sudo visudo -f /etc/sudoers.d/webteam

visudo sperrt die Richtliniendatei während der Bearbeitung und prüft vor dem Speichern ihre Syntax. Eine fehlerhafte Richtlinie kann dazu führen, dass Administratoren sudo nicht mehr verwenden können. Nenne die Datei webteam, nicht webteam.conf: Beim Einbinden des Verzeichnisses überspringt sudo Namen, die einen Punkt enthalten oder auf ~ enden.

Dateien im eingebundenen Verzeichnis werden in der Reihenfolge ihrer Namen gelesen. Treffen mehrere Regeln zu, bestimmt die letzte passende Regel das Ergebnis; die am spezifischsten wirkende Regel gewinnt nicht unbedingt. Die Einbindung steht normalerweise gegen Ende der Hauptrichtlinie, sodass eine zusätzliche Datei eine früher geschriebene Regel beeinflussen kann.

Eine bestimmte Aktion erlauben

Ein Team, das einen Webdienst betreut, könnte Folgendes erhalten:

%webteam ALL=(root) /usr/bin/systemctl restart nginx

Ein Mitglied kann sudo systemctl restart nginx ausführen. Die Regel gibt den vollständigen Befehlspfad und seine Argumente an. Sie erlaubt weder systemctl stop nginx noch bash. Prüfe die wirksamen Rechte mit sudo -l; ein Administrator kann Bobs Richtlinie mit sudo -l -U bob prüfen.

Auch das erlaubte Programm ist wichtig. Eine root-Shell kann alles tun. Editoren und Pager können Shells starten und uneingeschränktes cp oder tee kann geschützte Konfigurationen überschreiben. Eine scheinbar kurze Befehlsliste kann daher volle Kontrolle gewähren.

Entscheiden, ob ein Passwort nötig ist

NOPASSWD: entfernt die Authentifizierungsabfrage für einen passenden Befehl:

backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh

Das kann eine automatisierte Aufgabe ermöglichen. Das Skript muss unter der Kontrolle von root stehen: Kann backup es überschreiben, kann das Konto seinen Inhalt durch einen beliebigen root-Befehl ersetzen. Begrenze die erlaubte Aktion und schütze zugleich das Skript.

Defaults-Zeilen ändern Richtlinieneinstellungen. Defaults timestamp_timeout=10 legt einen Authentifizierungszeitstempel von zehn Minuten fest; Defaults logfile=/var/log/sudo.log wählt eine zusätzliche Protokolldatei. Diese Einstellungen steuern das Verhalten von sudo, während Befehlsregeln die erlaubten Aktionen bestimmen.

Beim Anlegen eines Kontos werden eine Identität, eine Anmeldeumgebung und häufig ein Home-Verzeichnis eingerichtet. Wenn du die Optionen ausdrücklich wählst, wird das Ergebnis über Distributionen hinweg vorhersehbar.

Ein reguläres Konto anlegen

Angenommen, die Gruppe developers existiert bereits. Lege Priyas Konto an und setze ihr Passwort mit zwei Befehlen:

sudo useradd -m -s /bin/bash -c "Priya Shah" -G developers priya
sudo passwd priya

-m erstellt /home/priya und kopiert die Startdateien aus /etc/skel. -s /bin/bash wählt Bash als Login-Shell und -c liefert den Kommentar. -G developers fügt eine zusätzliche Gruppenmitgliedschaft hinzu; mehrere Gruppennamen bilden eine kommagetrennte Liste ohne Leerzeichen. Das Konto erhält normalerweise auch eine private primäre Gruppe.

Der erste Befehl fügt Kontoeinträge zu /etc/passwd und /etc/shadow sowie bei Bedarf Gruppeneinträge zu /etc/group und /etc/gshadow hinzu. Das anfängliche Passwortfeld ist gesperrt, häufig mit ! oder !!. Das Konto existiert, bevor es ein verwendbares Passwort hat. passwd priya legt dieses Passwort fest; die Eingabeaufforderung hält das Passwort von der Befehlszeile fern.

Standardwerte der Distributionen verstehen

useradd ist der systemnahe Befehl zum Anlegen von Konten, der auf Linux-Distributionen verwendet wird. Debian und Ubuntu stellen außerdem ein interaktives Skript adduser bereit, das Angaben abfragt und ein Home-Verzeichnis erstellt. Auf Systemen der Red-Hat-Familie ist adduser ein anderer Name für useradd und bietet daher nicht denselben interaktiven Ablauf.

Ohne ausdrückliche Optionen hängt useradd von lokalen Standardwerten ab. Die Standardwerte der Red-Hat-Familie erstellen gewöhnlich ein Home-Verzeichnis; die von Debian und Ubuntu nicht, sofern -m nicht angegeben wird. Auch die Standard-Shell kann sich unterscheiden. Prüfe mit useradd -D Standardwerte wie das Basisverzeichnis für Home-Verzeichnisse und die Shell. /etc/default/useradd und /etc/login.defs liefern Einstellungen unter anderem für UID-Bereiche, private Gruppen und Passwortalter.

Ein anderes Home-Verzeichnis oder eine andere Identität angeben

Nützliche Optionen beschreiben getrennte Teile des Kontos:

Ein Home-Pfad im Eintrag erstellt das Verzeichnis nicht von selbst. Kombiniere -d mit -m, wenn das neue Home-Verzeichnis erstellt werden muss. Unter Debian kann ein ansonsten gültiges Konto ohne -m bei der Anmeldung ohne nutzbares Home-Verzeichnis dastehen.

Für eine Dienstidentität fordert sudo useradd -r -s /usr/sbin/nologin backupsvc eine System-UID und eine nicht interaktive Shell an. Systemkonten haben standardmäßig kein Home-Verzeichnis. Die nologin-Shell verhindert eine gewöhnliche interaktive Shell-Anmeldung unter dieser Identität.

Die Einrichtung prüfen

Führe getent passwd priya, id priya und ls -la /home/priya aus. Prüfe den Home-Pfad, die Shell, die primäre Gruppe, zusätzliche Gruppen und kopierte versteckte Dateien. /etc/skel ist eine Vorlage: Fügst du dort .bash_aliases hinzu, wirkt sich das auf später erstellte Home-Verzeichnisse aus, nicht auf bereits bestehende. Verwende einfache Kontonamen in Kleinbuchstaben mit Ziffern, Bindestrichen oder Unterstrichen nach dem Anfangsbuchstaben; Leerzeichen und ungewöhnliche Namen werden von vielen Werkzeugen abgelehnt oder falsch verarbeitet.

Ein Konto kann ein neues Passwort, ein anderes Home-Verzeichnis, eine vorübergehende Zugriffssperre oder eine dauerhafte Entfernung benötigen. Diese Vorgänge ändern unterschiedliche Teile des Kontos. Kläre daher das gewünschte Ergebnis, bevor du einen Befehl wählst.

Ein Passwort ändern oder sein Alter verwalten

Führe passwd aus, um dein eigenes Passwort zu ändern, normalerweise nachdem du das aktuelle eingegeben hast. Ein Administrator verwendet sudo passwd priya, um Priyas Passwort festzulegen, ohne das alte zu kennen. Prüfungen der Passwortqualität können kurze oder einfache Passwörter ablehnen.

sudo passwd -S priya meldet den Passwortstatus. sudo passwd -l priya sperrt das Passwort, indem ! vor seinen Hash gesetzt wird, und sudo passwd -u priya hebt die Sperre auf. sudo passwd -e priya lässt das Passwort ablaufen, sodass der Benutzer bei der nächsten Anmeldung ein anderes wählen muss. Ein Passwort ablaufen zu lassen ist nützlich, wenn ein vorläufiges Passwort vergeben wird.

Verwende sudo chage -l priya, um die Daten zum Passwortalter zu prüfen. Zum Beispiel:

sudo chage -M 90 -m 1 -W 7 priya

Das Höchstalter beträgt 90 Tage, der Mindestabstand zwischen Änderungen einen Tag und die Warnungen beginnen sieben Tage vor dem Ablauf. Diese Werte gelangen in /etc/shadow. sudo chage -E 2026-12-31 priya legt das Ablaufdatum des gesamten Kontos getrennt von der Passwortlaufzeit fest.

Zugriff sperren, ohne Einträge zu löschen

Eine Passwortsperre blockiert die Passwortauthentifizierung. Sie entfernt keine SSH-Schlüssel und verhindert nicht jedes andere Authentifizierungsverfahren. Um künftige Anmeldungen am Konto eines ausscheidenden Benutzers zu verhindern, sperre das Passwort und setze ein vergangenes Kontoablaufdatum, zum Beispiel mit sudo usermod -e 1 priya. Der Wert 1 ist eine Tageszählung im Januar 1970, sodass dieses Datum bereits vergangen ist. Bereits laufende Prozesse werden dadurch nicht beendet; um sie musst du dich gesondert kümmern.

Ein bestehendes Konto ändern

usermod kann mit -c den Kommentar, mit -s die Shell und mit -d den Home-Pfad ändern. Kombiniere -d und -m, um den Inhalt des Home-Verzeichnisses zu verschieben, wie in sudo usermod -d /data/priya -m priya. -l newname ändert den Anmeldenamen, aber das Home-Verzeichnis und die private Gruppe behalten ihre bisherigen Namen, sofern sie nicht ebenfalls geändert werden. -L und -U sperren und entsperren das Passwort.

Um eine zusätzliche Gruppenmitgliedschaft hinzuzufügen, führe sudo usermod -aG developers priya aus. Das -a bedeutet Anhängen. Ohne es ersetzt usermod -G developers priya Priyas gesamte Liste zusätzlicher Gruppen; eine frühere Mitgliedschaft in sudo kann verschwinden. Ihre primäre Gruppe ist eine getrennte Einstellung, die mit -g gesteuert wird.

Das Konto entfernen und seine Dateien behandeln

sudo userdel priya löscht die Kontoeinträge, lässt aber das Home-Verzeichnis bestehen. sudo userdel -r priya entfernt auch das Home-Verzeichnis und die zwischengespeicherte Post. Der normale Befehl verweigert das Entfernen, solange für den Benutzer noch Prozesse laufen.

Dateien an anderen Stellen behalten die numerische UID ihres Eigentümers. Nach dem Löschen des Kontos kann eine Auflistung 1003 als Eigentümer zeigen, weil ihr kein Name zugeordnet ist. Wird diese UID für ein neues Konto wiederverwendet, wird dieses Konto Eigentümer der alten Dateien. Verwende sudo find / -nouser, um Dateien ohne passenden Benutzer zu finden, und archiviere sie oder ordne sie neu zu. Sperre beim Ausscheiden einer Person zuerst künftige Anmeldungen, kümmere dich um laufende Aktivitäten und sichere benötigte Dateien. Lösche das Konto, wenn diese Aufgaben abgeschlossen sind.

Ein gemeinsam genutztes Verzeichnis braucht eine Gruppe, Mitglieder und Verzeichnisrechte, die diesen Mitgliedern die Arbeit ermöglichen. Nach einer Änderung der Mitgliedschaft können die Kontodatenbank und die Gruppen einer bereits laufenden Shell vorübergehend voneinander abweichen.

Die Gruppe anlegen und verwalten

sudo groupadd developers weist die nächste freie GID zu. Ergänze -g 1500, um eine bestimmte GID zu wählen, oder -r für eine Systemgruppe. Prüfe mit getent group developers; ein leeres letztes Feld bedeutet, dass noch keine zusätzlichen Mitglieder aufgeführt sind.

Füge ein Mitglied mit einem dieser Befehle hinzu:

sudo usermod -aG developers priya
sudo gpasswd -a priya developers

sudo gpasswd -d priya developers entfernt diese zusätzliche Mitgliedschaft. sudo gpasswd -M alice,bob developers legt die gesamte Mitgliederliste fest und ersetzt die bisherige. Wähle je nach gewünschter Änderung das Hinzufügen, Entfernen oder Ersetzen.

Die Gruppen einer Sitzung aktualisieren

Nach dem Hinzufügen von Priya fragt id priya die Kontodatenbank ab und zeigt die neue Mitgliedschaft sofort. id ohne Argumente in ihrer bestehenden Shell zeigt die Gruppen, die diese Shell tatsächlich verwendet. Sie wurden beim Beginn der Sitzung festgelegt.

Eine neue Anmeldung lädt die neue Liste. newgrp developers bietet einen anderen Weg: Der Befehl startet eine neue Shell mit developers als primärer Gruppe. Verwende exit, um diese Shell zu verlassen. Untersuche bei einem verweigerten Vorgang die Identität in der Sitzung, die den Vorgang ausführt, und nicht nur den Datenbankeintrag.

Eine Gruppe umbenennen oder löschen

sudo groupmod -n devteam developers ändert den Namen, behält aber die GID bei. Bestehende Dateien verweisen weiterhin auf dieselbe numerische Gruppe. Dagegen ändert sudo groupmod -g 1600 developers die Nummer der Gruppe. Dateien, die noch die alte GID 1005 tragen, müssen nachbearbeitet werden; finde sie mit sudo find / -gid 1005 und weise ihnen dann mit chgrp die gewünschte Gruppe zu.

sudo groupdel developers verweigert das Löschen, wenn ein bestehender Benutzer die Gruppe noch als primäre Gruppe hat. Lege vor dem Löschen mit usermod -g eine andere primäre Gruppe fest. Das Löschen eines Gruppennamens entfernt keine Dateien, die seine frühere GID tragen.

Ein Teamverzeichnis einrichten

Für das Webteam von Priya und Kenji:

sudo groupadd webteam
sudo usermod -aG webteam priya
sudo usermod -aG webteam kenji
sudo mkdir /srv/web
sudo chgrp webteam /srv/web
sudo chmod 2770 /srv/web

Nach erneuter Anmeldung können beide Benutzer Dateien in /srv/web erstellen. Modus 2770 gibt Eigentümer und Gruppe rwx, Anderen --- und setzt SGID auf dem Verzeichnis. Eine neue Datei erhält die Gruppe webteam, auch wenn die primäre Gruppe ihres Erstellers dessen private Gruppe ist. Neue Unterverzeichnisse erben ebenfalls SGID.

Das Verzeichnis macht die Teammitgliedschaft nutzbar und hält Andere vom Betreten ab, aber jede Datei hat weiterhin ihren eigenen Modus. Bei einem üblichen angeforderten Dateimodus von 666 gibt eine umask von 002 der Gruppe Schreibrecht, während 022 der Gruppe nur Leserecht lässt. Wenn Teammitglieder die Dateien der jeweils anderen bearbeiten müssen, prüfe neben dem Verzeichnis auch diese Standardwerte für die Erstellung.

Ein langes Listenformat zeigt die für eine Zugriffsentscheidung nötigen Informationen in einer Zeile. Lies Eigentümer und Gruppe zusammen mit den neun Rechtebits; die Bits allein sagen nicht, welche Rechte eine bestimmte Person erhält.

Ein langes Listenformat entschlüsseln

-rw-r----- 1 priya developers 2048 Oct 22 09:15 report.txt

Das erste Feld enthält Dateityp und Zugriffsrechte. Die folgenden Felder geben die Anzahl der Hardlinks, den Eigentümer, die zugeordnete Gruppe, die Größe in Byte, den Änderungszeitpunkt und den Namen an. Diese reguläre Datei gehört Priya und der Gruppe developers. Sie ist 2048 Byte groß; die angezeigte Zeit gibt die letzte Inhaltsänderung an.

Das erste Zeichen ist - für eine reguläre Datei, d für ein Verzeichnis oder l für einen symbolischen Link. Außerdem können dir c und b für zeichen- und blockorientierte Geräte, p für eine benannte Pipe und s für einen Socket begegnen.

Teile die nächsten neun Stellen in drei Tripel:

In jedem Tripel bedeuten die Stellen in dieser Reihenfolge Lesen, Schreiben und Ausführen. Ein Bindestrich kennzeichnet ein fehlendes Recht und keine leere Stelle, die beim Zählen übersprungen wird.

Genau eine Klasse auswählen

Bei einer gewöhnlichen Rechteprüfung fragt Linux:

1. Stimmt der Benutzer des Prozesses mit dem Dateieigentümer überein? Verwende das Eigentümertripel.
2. Stimmt andernfalls eine seiner Gruppen mit der Gruppe der Datei überein? Verwende das Gruppentripel.
3. Verwende andernfalls das Tripel für Andere.

Die Klassen werden nicht addiert. Angenommen, Priya besitzt eine Datei, deren vollständige Zeichenfolge für Typ und Modus ----rw-rw- lautet. Ihr Eigentümertripel ist ---, sodass sie die Datei über die gewöhnlichen Bits nicht lesen kann, obwohl Gruppe und Andere rw- haben. Als Eigentümerin kann sie den Modus ändern. Ein weniger restriktives Tripel für Gruppe oder Andere setzt das ausgewählte Eigentümertripel nicht außer Kraft.

Root kann gewöhnliche Prüfungen der Lese- und Schreibrechte umgehen. Um eine reguläre Programmdatei auszuführen, braucht selbst root mindestens ein Ausführungsbit auf ihr. Für eine Modusprüfung sind daher sowohl die Identität des Benutzers als auch der versuchte Vorgang nötig.

Verzeichnisse und Nummern untersuchen

ls -ld /srv/web listet das Verzeichnis selbst auf. Ohne -d listet ls -l /srv/web normalerweise Einträge darin auf, was von einer Beschränkung auf dem Verzeichnis ablenken kann. ls -a bezieht versteckte Namen ein, während ls -n Eigentümer und Gruppen numerisch anzeigt. Dateien speichern UIDs und GIDs; wurde ein Konto oder eine Gruppe gelöscht, kann auch eine gewöhnliche Auflistung die verbleibende Nummer zeigen.

Für eine knappe Ausgabe führe aus:

stat -c '%A %a %U %G %n' report.txt

Der Befehl kann -rw-r----- 640 priya developers report.txt anzeigen und stellt dabei Buchstaben und Oktalziffern nebeneinander. Ein + nach den Buchstaben signalisiert zusätzliche Einträge in einer Zugriffskontrollliste. Ein symbolischer Link zeigt gewöhnlich lrwxrwxrwx; Linux verwendet für den Zugriff die Rechte des Ziels und nicht die angezeigten Bits des Links.

Lesen, Schreiben und Ausführen beschreiben unterschiedliche Aktionen auf Dateien und Verzeichnissen. Ein Verzeichnis speichert Namen, die zu Dateien führen. Für das Ändern eines Dateiinhalts und das Entfernen seines Namens gelten daher unterschiedliche Rechteprüfungen.

Das Bit dem Objekt zuordnen

An eine Datei mit Schreibrecht, aber ohne Leserecht kann etwas angehängt werden, ohne sie zu lesen. Eine Shell kann zum Beispiel eine beschreibbare Protokolldatei für echo text >> log.txt öffnen, selbst wenn cat log.txt fehlschlägt. Ein Editor braucht häufig sowohl Lese- als auch Schreibrecht, weil er zuerst den vorhandenen Inhalt lädt.

Ein als ./backup.sh ausgeführtes Skript braucht Ausführungsrecht und muss für seinen Interpreter lesbar sein. Ist das Skript lesbar, hat aber kein Ausführungsrecht, kann bash backup.sh es dennoch lesen und ausführen: Bash ist in diesem Befehl das ausführbare Programm.

Auflisten und Durchsuchen unterscheiden

Das Leserecht auf einem Verzeichnis erlaubt dir, Namen zu sehen. Das Ausführungsrecht auf einem Verzeichnis, auch Durchsuchungsrecht genannt, erlaubt dir, einen Eintrag über seinen Namen zu erreichen. Mit Lese-, aber ohne Ausführungsrecht kann ls Namen zeigen, während ls -l ihre Details nicht abrufen kann und möglicherweise Fehler und Fragezeichen anzeigt. Du kannst die benannten Dateien durch dieses Verzeichnis nicht öffnen.

Mit Ausführungs-, aber ohne Leserecht ist das Umgekehrte möglich: Du kannst notes.txt erreichen, wenn du den genauen Namen bereits kennst, aber das Verzeichnis nicht auflisten, um die Namen herauszufinden. Der Modus der Datei selbst muss den gewünschten Zugriff weiterhin erlauben.

Den gesamten Pfad verfolgen

Um /home/priya/notes/public.txt zu lesen, braucht Kenji Ausführungsrecht auf jedem Verzeichnis im Pfad und Leserecht auf der Datei. Hat /home/priya den Modus 700, lautet sein Tripel für Andere ---; Kenji kommt dort nicht weiter, selbst wenn public.txt den Modus 644 hat. Mehr Leserecht auf der Datei kann ein fehlendes Durchsuchungsbit auf einem darüberliegenden Verzeichnis nicht beheben.

Verwende ls -ld /home/priya /home/priya/notes, um die Verzeichnisse selbst zu untersuchen. Wähle auf jeder Ebene die für Kenji geltende Klasse und prüfe ihr Ausführungsbit. Die maßgebliche Klasse kann von einem Verzeichnis zum nächsten wechseln, weil deren Eigentümer und Gruppen unterschiedlich sein können.

Löschen und Umbenennen vorhersagen

Das Löschen einer Datei entfernt einen Verzeichniseintrag. Kenji braucht Schreib- und Ausführungsrecht auf dem enthaltenden Verzeichnis, nicht Schreibrecht auf der Datei. In einem gewöhnlichen beschreibbaren Verzeichnis ohne Sticky-Bit kann er Priyas schreibgeschützte Datei entfernen. Umgekehrt erlaubt ihm das Eigentum an einer Datei nicht, sie aus einem Verzeichnis zu löschen, auf dem ihm das Schreibrecht fehlt.

Das Entfernen des Schreibrechts von einer Datei schützt daher ihren Inhalt vor Änderungen, aber nicht ihren Namen vor der Entfernung. Das Sticky-Bit eines Verzeichnisses schränkt das Löschen und Umbenennen in gemeinsam beschreibbaren Verzeichnissen anhand des Eigentümers ein. Der Zugriff auf Dateien und der Zugriff auf Verzeichniseinträge beantworten unterschiedliche Fragen.

Verwende chmod, um die Rechte einer Datei oder eines Verzeichnisses zu ändern, das dir gehört. Root kann sie ebenfalls ändern. Schreibzugriff über eine Gruppe erlaubt dir, den Inhalt einer Datei zu ändern, macht dich aber nicht zum Eigentümer und erlaubt dir nicht, ihren Modus festzulegen.

Eine gezielte symbolische Änderung vornehmen

Ein symbolischer Modus enthält eine Klasse, einen Operator und Bits. Die Klassen sind u für Eigentümer, g für Gruppe, o für Andere und a für alle drei. + fügt Rechte hinzu, - entfernt sie und = legt die Rechte dieser Klasse genau fest.

chmod u+x deploy.sh
chmod go-w notes.txt
chmod u=rw,g=r,o= report.txt

Der erste Befehl fügt nur das Ausführungsbit des Eigentümers hinzu. Der zweite entfernt das Schreibrecht für Gruppe und Andere und behält ihre übrigen Bits bei. Der dritte gibt dem Eigentümer Lese- und Schreibrecht, der Gruppe Leserecht und Anderen keine Rechte: rw-r-----.

Gib die Klasse an, wenn du eine genaue Änderung möchtest. Lässt du sie weg, wie in chmod +w notes.txt, schränkt die umask ein, welche Bits der Klassen betroffen sind. Bei umask 022 fügt dieser Befehl das Schreibrecht nur für den Eigentümer hinzu; chmod a+w notes.txt bezieht ausdrücklich alle drei Klassen ein.

Jedes Tripel in eine Oktalziffer umrechnen

Lesen hat den Wert 4, Schreiben 2 und Ausführen 1. Addiere die in jeder Klasse vorhandenen Werte:

Teile rw-r----- in rw-, r--, ---: Die Ziffern sind 6, 4, 0. chmod 640 report.txt setzt diese neun gewöhnlichen Bits unabhängig vom vorherigen gewöhnlichen Modus. Kehre den Vorgang für 750 um: 7 ergibt rwx, 5 ergibt r-x und 0 ergibt ---, zusammen rwxr-x---.

Einen zweckmäßigen Endmodus wählen

Modus 600 hält eine Datei für ihren Eigentümer privat. Modus 644 erlaubt anderen Benutzern, eine gewöhnliche Datei zu lesen. Modus 664 erlaubt außerdem der Gruppe, sie zu bearbeiten. Private Verzeichnisse verwenden häufig 700, für die Gruppe lesbare Verzeichnisse 750 und für die Gruppe beschreibbare Verzeichnisse 770. Programme oder öffentliche Verzeichnisse verwenden häufig 755.

Dieselben Ziffern erlauben bei unterschiedlichen Objekten unterschiedliche Aktionen. Wendest du 644 auf ein Verzeichnis an, entfernst du das Ausführungsrecht für jede Klasse. Nicht einmal der Eigentümer kann es dann noch betreten oder Dateien darüber öffnen. Verwende einen Verzeichnismodus mit Durchsuchungsrecht für die Personen, die Zugriff benötigen.

Änderungen auf einen Baum anwenden

chmod -R 755 site/ macht auch jede gewöhnliche Datei ausführbar. Verwende für einen Baum mit Verzeichnissen und gewöhnlichen Dokumenten das bedingte Ausführungsrecht:

chmod -R u=rwX,go=rX site/

Das große X fügt das Ausführungsrecht für Verzeichnisse und für Dateien hinzu, die bereits ein Ausführungsbit haben. Nicht ausführbare Dateien erhalten 644; Verzeichnisse erhalten 755. Bereits ausführbare Dateien behalten ihr Ausführungsrecht. So bleibt das Durchqueren möglich, ohne jedes Dokument als Programm ausführbar zu machen. Sonderbits sind davon getrennt: GNU chmod behält SUID und SGID auf Verzeichnissen bei, sofern du sie nicht ausdrücklich entfernst, etwa mit chmod g-s site/.

Eigentümer und Gruppenzuordnung bestimmen, wessen Rechtetripel geprüft werden. Eine passende Zuordnung kann ein Arbeitsverzeichnis reparieren, das versehentlich mit sudo erstellt wurde, ohne allen anderen weitergehenden Zugriff zu gewähren.

Die Formen von chown lesen

chown kann einen Benutzer, eine Gruppe oder beides ändern:

Auch numerische IDs funktionieren, wie in sudo chown 1002:1005 report.txt. Die Namen werden in Nummern aufgelöst; die Datei speichert diese Nummern.

Nur root kann eine Datei einem anderen Eigentümer übertragen. Ein Eigentümer kann die Gruppe seiner eigenen Datei zu einer Gruppe ändern, der er angehört. Priya kann also chgrp webteam plan.txt verwenden, wenn ihr die Datei gehört und sie zu webteam gehört. Um sie der Gruppe finance zuzuweisen, wäre auch eine Mitgliedschaft in dieser Gruppe nötig. Dass ein anderes Mitglied die Datei bearbeiten kann, erlaubt ihm nicht, ihren Eigentümer oder Modus zu ändern.

Ein versehentlich root gehörendes Verzeichnis reparieren

Kenji hat einen Erstellungsbefehl mit sudo ausgeführt. Die Auflistung lautet:

drwxr-xr-x 2 root root 4096 Oct 22 10:02 /home/kenji/app

Er ist nicht der Eigentümer und gehört nicht zur zugeordneten Gruppe, sodass er das r-x für Andere erhält. Er kann das Verzeichnis untersuchen und betreten, aber keine Einträge erstellen, weil das Schreibrecht fehlt. Würde das Verzeichnis für alle beschreibbar gemacht, gewährte das mehr Zugriff, als sein Projekt benötigt.

Gehört das Projekt Kenji, stellt sudo chown -R kenji: ~/app sein Eigentum und seine Anmeldegruppe im gesamten Verzeichnis wieder her. Sein Eigentümertripel ist nun rwx, sodass er Dateien erstellen kann. Prüfe vor jedem rekursiven Befehl zur Änderung der Eigentumszuordnung den Zielpfad: Die Anwendung auf /etc oder /usr kann den Systembetrieb stören. -R bedeutet das Verzeichnis und alles darunter.

Eigentümer nach Dateioperationen vorhersagen

Eine neu erstellte Datei gehört dem Benutzer des erstellenden Prozesses. Ihre Gruppe stammt normalerweise aus der primären Gruppe dieses Prozesses oder aus einem übergeordneten SGID-Verzeichnis. Wird mit cp eine gewöhnliche neue Kopie erstellt, wird daher der aufrufende Benutzer ihr Eigentümer. Ein mv innerhalb desselben Dateisystems ändert den Speicherort einer bestehenden Datei und behält ihren Eigentümer und ihre Gruppe bei. Kopieroptionen, die die Eigentumszuordnung erhalten, verhalten sich anders als eine gewöhnliche neue Kopie.

Dieser Unterschied erklärt, warum das Verschieben einer alten Datei in ein gemeinsam genutztes Verzeichnis nicht die Gruppenvererbungsregel dieses Verzeichnisses auf sie anwendet. SGID wirkt bei der Erstellung; verwende chgrp, wenn die Gruppe einer bestehenden Datei geändert werden muss.

Identität und Zugriff verbinden

Die Zuweisung von webteam mit chgrp legt fest, für wen die Gruppenklasse steht. Sie fügt kein Lese- oder Schreibrecht für die Gruppe hinzu. Verwende chmod, um nach der Wahl der Gruppe die benötigten Bits zu setzen. Eine Änderung der Eigentumszuordnung einer ausführbaren Datei kann auch SUID- oder SGID-Rechte entfernen; prüfe den resultierenden Modus, wenn diese Bits wichtig sind.

Die Rechte einer neuen Datei ergeben sich aus zwei Angaben: dem Modus, den das erstellende Programm anfordert, und der umask des Prozesses. Die Maske entfernt angeforderte Bits; sie fügt niemals Rechte hinzu, die das Programm nicht angefordert hat.

Mit dem angeforderten Erstellungsmodus beginnen

Editoren und Shell-Umleitungen fordern für gewöhnliche neue Dateien normalerweise 666 oder rw-rw-rw- an. Für die Erstellung von Verzeichnissen wird gewöhnlich 777 oder rwxrwxrwx angefordert. Eine umask ist eine Zusammenstellung von Bits, die aus diesem angeforderten Modus entfernt werden. Ein Bit bleibt nur erhalten, wenn der angeforderte Modus es enthält und die Maske nicht.

Bei umask 022 bleiben alle angeforderten Eigentümerbits erhalten, das Schreibrecht der Gruppe und das Schreibrecht für Andere werden entfernt. Eine Datei erhält 644, ein Verzeichnis 755. Lies jede Ziffer als Bits, nicht als gewöhnliche Dezimalzahl.

Bei 027 verliert die Gruppe das Schreibrecht, während Andere alle drei Bits verlieren. Das ist nützlich, wenn ein Team neue Dateien lesen soll, Benutzer außerhalb des Teams aber keinen Zugriff haben sollen. Bei 002 bleibt das Schreibrecht der Gruppe erhalten; die zugeordnete Gruppe der Datei bestimmt weiterhin, wer es erhält.

Warum Subtraktion nicht funktioniert

Nimm den angeforderten Dateimodus 666 und die Maske 033. Jede 3 bedeutet Schreiben plus Ausführen. Jedes angeforderte Dateitripel ist aber rw-: Das Ausführungsrecht fehlt bereits. Das Entfernen von Schreib- und Ausführungsrecht lässt für Gruppe und Andere r-- übrig, das Ergebnis ist also 644. Eine Subtraktion der Ziffern ergäbe 633 und würde fälschlich nahelegen, dass Ausführungsbits hinzukommen können.

Bei einem angeforderten Verzeichnismodus von 777 ergibt das Entfernen derselben Bits 744. Diesem Verzeichnis fehlt das Ausführungsrecht für Gruppe und Andere, sodass diese Klassen seine Einträge nicht erreichen können, obwohl sie Namen auflisten können. Eine Maske, die den gewünschten Dateimodus ergibt, kann bei Verzeichnissen zu einem unzweckmäßigen Ergebnis führen.

Deine Maske prüfen und setzen

Führe umask aus, um die aktuelle Einstellung zu sehen. Sie wird häufig mit einer führenden Null angezeigt, etwa als 0022. Die führende Null dient der Formatierung; Linux verwendet die neun gewöhnlichen Rechtebits. umask -S gibt erlaubte Bits aus, für 022 etwa u=rwx,g=rx,o=rx; ein Programm kann eine Teilmenge dieser Bits anfordern.

umask 027 ändert die aktuelle Shell und wird an die Programme vererbt, die sie startet. Bestehende Dateien behalten ihre Modi. Verwende chmod, wenn eine bereits erstellte Datei andere Rechte braucht.

Einen dauerhaften Standardwert wählen

Eine Zeile wie umask 027 in ~/.profile oder ~/.bashrc kann den Wert für die Shells setzen, die diese Startdatei lesen. Systemweite Standardwerte können aus /etc/profile oder UMASK in /etc/login.defs stammen. Distribution und Kontoeinrichtung bestimmen, welche Dateien wann gelesen werden.

Viele Systeme verwenden 022, während Einrichtungen mit privaten Gruppen für reguläre Benutzer häufig 002 verwenden. Ein Compiler kann ausführbare Ausgaben mit Modus 777 anfordern; bei 022 wird daraus 755. Der von einem Texteditor angeforderte Modus 666 hat keine Ausführungsbits, sodass das Schreiben eines Skripts dieses nicht selbst ausführbar macht.

Drei Sonderbits ergänzen das Verhalten über die gewöhnlichen Rechte für Eigentümer, Gruppe und Andere hinaus. Ihre Bedeutung hängt davon ab, ob das Objekt ein Programm oder ein Verzeichnis ist.

Die zusätzliche Ziffer erkennen

Eine führende Oktalziffer kombiniert SUID 4, SGID 2 und Sticky 1. Modus 4755 ist SUID plus der gewöhnliche Modus 755. Modus 2770 ist SGID plus 770. Modus 3770 kombiniert SGID und Sticky, weil 2 plus 1 gleich 3 ist.

In einem langen Listenformat teilen sich die Bits die Positionen für das Ausführungsrecht. Ein kleines s an der Eigentümerposition bedeutet SUID und Ausführungsrecht für den Eigentümer; ein kleines s an der Gruppenposition bedeutet SGID und Ausführungsrecht für die Gruppe. Ein kleines t an der Position für Andere bedeutet Sticky und Ausführungsrecht für Andere. Ein großes S oder T bedeutet, dass das Sonderbit gesetzt ist, das Ausführungsrecht an dieser Position aber fehlt.

SUID und SGID auf Programmen

SUID lässt eine ausführbare Datei mit der effektiven Identität ihres Eigentümers laufen. /usr/bin/passwd erscheint gewöhnlich als -rwsr-xr-x root root: Das Programm kann geschützte Passwortdaten aktualisieren und setzt dabei durch, wessen Passwort der aufrufende Benutzer ändern darf. Sein Start gibt dem aufrufenden Benutzer keine root-Shell. Linux ignoriert SUID auf Skripten und Verzeichnissen.

SGID auf einer ausführbaren Datei verwendet entsprechend die Gruppenidentität der Datei. Diese Bits gewähren Zugriff unter Kontrolle des Programms, daher ist dessen Verhalten wichtig. Setze SUID niemals auf einer Shell, einem Editor oder einem Skript. Ein Administrator kann reguläre SUID-Dateien mit sudo find / -perm -4000 -type f 2>/dev/null erfassen; verwende -perm -2000 für SGID-Dateien und vergleiche die Ergebnisse mit der erwarteten Systemeinrichtung.

SGID auf einem Teamverzeichnis

Auf einem Verzeichnis sorgt SGID dafür, dass neue Einträge die Gruppe des Verzeichnisses übernehmen und neue Unterverzeichnisse SGID erben. Angenommen, /srv/web gehört root:webteam, hat den Modus 2770 und wird als drwxrws--- angezeigt. Priya hat eine private primäre Gruppe, gehört aber zu webteam. Wenn sie index.html in diesem Verzeichnis erstellt, wird dessen Gruppe webteam.

Der gewöhnliche Modus der Datei hängt weiterhin von ihrer Erstellung ab. Bei einem angeforderten Dateimodus von 666 und umask 002 wird er zu 664 und Kenji, ein weiteres Teammitglied, kann sie bearbeiten. Bei 022 wird er zu 644, sodass Kenji nur Leserecht hat. SGID liefert die Gruppe, kein zusätzliches Schreibbit.

Verzeichnisse mit Sticky-Bit und das Löschen

Das Sticky-Bit schränkt das Löschen und Umbenennen ein: Bei vorhandenem Verzeichniszugriff kann ein Eintrag vom Eigentümer der Datei, dem Eigentümer des Verzeichnisses oder root entfernt werden. So sind gemeinsam beschreibbare Verzeichnisse nutzbar, ohne dass Benutzer die Einträge anderer entfernen können. /tmp und /var/tmp verwenden gewöhnlich 1777, angezeigt als drwxrwxrwt. Das Sticky-Bit verhindert keine Änderungen am Dateiinhalt, wenn der Dateimodus sie erlaubt. Linux ignoriert es auf regulären Dateien.

Setze Bits mit chmod u+s prog, chmod g+s /srv/web oder chmod o+t /srv/drop. Entferne sie mit u-s, g-s oder o-t. Bei GNU chmod behält chmod 755 /srv/web ein bestehendes SGID-Bit auf einem Verzeichnis bei; verwende chmod g-s /srv/web, um es ausdrücklich zu entfernen.

Ein Fehler „Permission denied“ bezeichnet einen fehlgeschlagenen Vorgang und nicht unbedingt einen falschen Dateimodus. Die Sperre kann an den Gruppen deiner Sitzung, einem übergeordneten Verzeichnis, der Datei selbst oder einer durch einen Befehl mit erhöhten Rechten entstandenen Eigentumszuordnung liegen.

Identität, Pfad, Klasse und Vorgang verfolgen

Beginne mit id ohne Argumente in der betroffenen Sitzung. Wurde kürzlich eine Gruppe hinzugefügt, vergleiche die aktive Liste mit id username, das die Datenbank abfragt. Eine erneute Anmeldung kann die neue Mitgliedschaft laden.

Untersuche als Nächstes den gesamten Pfad:

namei -l /srv/reports/q3.txt

namei -l zeigt Eigentümer, Gruppen und Modi entlang des Pfads. Du kannst auch jedes Verzeichnis mit ls -ld untersuchen. Wähle bei jedem Objekt die erste zutreffende Klasse: Eigentümer, andernfalls Gruppe, andernfalls Andere. Frag dich dann, was der versuchte Vorgang braucht. Lesen braucht r auf der Datei und Durchsuchungsrecht auf allen übergeordneten Verzeichnissen. Das Erstellen, Entfernen oder Umbenennen eines Eintrags braucht w und x auf seinem Verzeichnis, gegebenenfalls mit Einschränkungen durch das Sticky-Bit.

Den ersten blockierten Vorgang finden

Kenji gehört zu finance und versucht cat /srv/reports/q3.txt. Die relevanten Objekte sind:

drwxr-xr-x root  root     /srv
drwxr-x--- root  finance  /srv/reports
-rw------- maria finance  /srv/reports/q3.txt

Kenji kann /srv mit dem Ausführungsrecht für Andere durchqueren. Bei /srv/reports wählt seine Mitgliedschaft in finance das r-x der Gruppe, sodass er auch dort hindurchkommt. Bei q3.txt ist er nicht Maria und das finance-Tripel ist ---. Es fehlt das Leserecht der Gruppe auf der Datei.

Sollen finance-Mitglieder den Bericht lesen dürfen, kann Maria oder root chmod g+r /srv/reports/q3.txt ausführen. Der resultierende Modus ist 640. Er liefert das fehlende Recht, ohne der Gruppe Schreibrecht zu geben oder den Bericht für Andere zu öffnen. Ein Administrator kann mit sudo -u kenji cat /srv/reports/q3.txt testen und den Befehl dabei als Kenji statt als root ausführen.

Die kleinste Korrektur wählen

Eine passende Lösung kann sein, eine Teammitgliedschaft hinzuzufügen, Leserecht für die Gruppe zu setzen, den Eigentümer eines Projekts wiederherzustellen oder Durchsuchungsrecht für die vorgesehene Klasse auf dem Verzeichnis hinzuzufügen. chmod -R 777 gibt jedem lokalen Konto Schreibzugriff im gesamten Baum und macht gewöhnliche Dateien ausführbar. Zudem kann es nicht jede Ursache eines fehlgeschlagenen Zugriffs beheben.

Prüfe häufige Ursachen, bevor du einen großen Baum bearbeitest: eine inaktive neue Mitgliedschaft, fehlendes x auf einem übergeordneten Verzeichnis, mit sudo erstellte Arbeit im Eigentum von root und neue Dateien, deren umask benötigten Teamzugriff entfernt hat. FAT32- und exFAT-Laufwerke speichern keine nativen Linux-UIDs, -GIDs und -Modi; Einhängeoptionen liefern diese Werte, sodass chmod oder chown für einzelne Dateien fehlschlagen oder wirkungslos bleiben kann.

Private Daten privat halten

Ein privater SSH-Schlüssel wie ~/.ssh/id_ed25519 sollte normalerweise den Modus 600 haben; sein Verzeichnis .ssh hat gewöhnlich 700. SSH prüft den Schutz privater Schlüssel und kann einen zu weit zugänglichen Schlüssel ablehnen. /etc/shadow bleibt für gewöhnliche Benutzer unzugänglich. Administratoren mit vollen sudo-Rechten können den gewöhnlichen Schutz privater Dateien umgehen. Halte daher diese Gruppe klein und erlaube bestimmte Aktionen, wenn eine vollständige Administration nicht nötig ist.