Multiuser Handhabung in der Praxis
Bitte helft diese Seite für die internationale Distribution auch hier ins Englische zu übersetzen.

Inhalt

1. Zugriffskontrolle

1.1. Einleitung

Prinzipiell gibt es zwei unterschiedliche Stoßrichtungen. Eine ist die Lese und Schreibrechte für Benutzer so weit es geht einzuschränken und die Benutzer untereinander möglichst weitgehend abzuschotten. So ist es z.B. meistens bei Internetprovidern (ISP-Fall s.u.). Das Extrem wäre hier vielleicht jeden Benutzer in eine eigene isolierte virtuelle Maschiene zu "stecken". Das gegenteilige Extrem wäre Benutzern überhaupt keine Einschränkungen aufzuerlegen. Bei Letzterem könnten Benutzer zwar einfach zusammenarbeiten und ihre Arbeit verteilen, aber es kann auch genauso leicht zu beeinträchtigungen des Gesamtsystems oder anderer Benutzer kommen (und sei es nur duch ein Versehen).

Wenn Benutzer auf einem System gemeinsam und nebeneinander arbeiten können sollen bedarf es also einer Lösung zwischen diesen beiden Extremen. Eine solche Lösung für eine konstruktive MehrBenutzerUmgebung soll hier vorgestellt und erarbeitet werden. Die einzelnen Teilkonzepte sind in den folgenden Absätzen beschrieben.

1.1.1. Praxislösung für möglichst reibungslosen Betrieb

Es geht um einen gut handhabaren Mittelweg für einfaches zusammenarbeiten z.B. in Arbeitsgruppen. Dabei wird auf nicht ganz unzweifelhafte Sicherheitsmaßnahmen, wie z.B. das nichtlisten von Homeverzeichnissen lieber gleich verzichtet. So sind die meisten Konfigurationsdateinamen sind sowieso bekannt, und es wär nur zu leicht sich auch für andere Dateien vorschnell in falscher Sicherheit zu wähnen.

1.1.1.1. Verwenden von privaten Gruppen und "umask 002"

Für eine grundlegendere Erklärung siehe DateiRechte:

Wenn mehr als ein Benutzer an einem System arbeitet und diese gemeinsam 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 wird (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.

Bei Debian und RedHat/Fedora sind private Gruppen und umask 002 Standard.

Wenn jetzt eine Gruppe von Benutzern gemeinsam Zugriff auf Dateien haben soll, braucht man nur ein Verzeichnis erstellen, es der der gewünschten Gruppe zuordnen, und das "Set Group ID" Attribut für das Verzeichnis zu setzten. ("chgrp <Gruppe> <Verzeichnis>" und "chmod g+s <Verzeichnis>") Damit werden neu erstellte Dateien in dem Verzeichnis der Arbeitsgruppe zugeordnet, und durch die entsprechende umask Einstellung bekommen alle Mitglieder der Gruppe auch automatisch Schreibzugriff.

User und Gruppen IDs in einem Netz brauchen auf jeden Fall gewisse Überlegungen um die Arbeit der Benutzer und Administatoren zu erleichtern, und es nicht zu Überschneidungen zwischen lokalen und Netzwerkaccounts (NIS, NFS) kommt. IDs sollten sich auch bei unterschiedlichen Distributionen oder *nix Systemen nicht überschneiden.

Bei Debian sieht es so aus:

Näheres in den Debian Richtlinien und zu den einzelnen Standard Benutzern und Gruppen von Debian in /usr/share/doc/base-passwd/users-and-groups.html, einige kleine Tabelle ist auch hier zu finden.

1.1.1.2. Weitere Gruppenzugehörigkeiten

Außer der primären Mitgliedschaft eines Benutzer in seiner eigenen privaten Gruppe, werden Benutzer in der Regel auch weiteren Gruppen angehören. Beispielsweise allgemeiner Statusgruppen wie "user", "employee", "student", "teacher", "staff", ggf. von Hardwarebenutzergruppen wie "dialout" "dip" "audio" etc. und/oder auch speziellen Arbeitsgruppen wie z.B "Buchhaltung" oder "Bildbearbeitung" die Schreibzugriff auf die entsprechenden Daten bekommen.

Die Gruppen denen ein neuer Benutzer standardmäßig angehört werden bei Suse in /etc/default/adduser mit GROUPS=gruppe1,gruppe2 angegeben, für Debian siehe u.a. "man adduser" und hier ff. (adduser templates).

Vorhandene Grupen in Debian:

Es kann Sinn machen zur einfacheren Kategorisierung von Benutzern und Gruppen z.B. für die Auswahl von Gruppen noch weitere Bereiche zu definieren. So könnte man für User Private Groups (UPG) z.B wie folgt planen:

Note that "RH screwups" isn't directed at RH, but when I or another
admin mistakenly use the unmodified RH tools to create new users.
RH useradd by default starts at 500. (And note that laptop owners
and some others have sudo priviledges sufficient to create users,
so this is not a small problem. 100 should be sufficient to deal with

Tabellen Idee stammt von hier.

1.1.1.3. /etc/skel Homeverzeichnisvorlage für neue Benutzer

Über den /etc/skel Mechanismus können neue Benutzer mit Unterverzeichnissen versorgt werden die eine einfache und geordnete Möglichkeit des Datenaustausches zwischen Benutzern erlaubt. Und zwar ganz ohne manuelle oder skriptbasierte Anpassungen einzelner Dateirechte.

Durch gezielte Vorgabe von Rechten auf ein paar vorgegebene Unterverzeichnisse ist es für die Benutzer sehr einfach zu bestimmen wie von Anderen auf ihre Dateien zugegriffen werden kann. Und zwar einfach durch die Wahl des Speicherortes. Außerdem können die Rechte der vorgegebenen Verzeichnisse als Beispiele für eigene Dateien und Verzeichnisse dienen. Die Erfahrung zeigt das unerfahrene Benutzer sonst leicht unüberlegt zuviel freigeben, oder eigenständig gar nichts freigeben können.

Beispiel für Vorgabe-Unterverzeichnisse:

/home/tux/priv                  tux tux drwx------      (privates Unterverzeichnis)
/home/tux/pub                   tux tux drwx---r-x      (veröffentliches Unterverzeichnis)
/home/tux/incoming              tux tux drwx--s-wt      (Eingangskorb für Dateien von Anderen)
/home/tux/public_html   tux httpd       drwxr-x---      (Verzeichnis für Hompage) 

Die Rechte der Homeverzeichnisse selbst können weiterhin wie üblich angelegt sein:

/home/tux               tux tux drwxr-xr-x      (Heimatverzeichnis lesbar für alle Benutzer) 

Die Dateien direkt im Heimatverzeichnis sind wie auf Unix Sytemen üblich auch für Andere sichtbar. Weitere Rechte sind damit abhänging von den jeweiligen Dateirechten. Unkritische Konfigurationsdateien z.B werden üblicherweise auch für Andere zum lernen lesbar erstellt und gehalten. Programme wie z.B. ssh die private Daten wie die Schlüssel speichern achten zusätzlich auch selbst auf sichere DateiRechte.

Anmerkung: Mit hife von /etc/skel können zwar auch private Konfigurationdateien (Einstellungen) für Benutzer zentral vorgegeben werden, allerdings ist dies nicht zu empfehlen! Besser ist es die Systemweite konfiguration, meist in /etc oder einem weiteren Unterverzeichnis hiervon, entsprechend anzupassen weil diese nur an einer stelle gepflegt werden braucht und somit auch nachträglich einfach für alle angepasst werden kann. Falls keine zentrale Konfigurtionsmöglichkeit besteht kann man auch Symlinks auf zentrale Dateien anstatt die Dateien selbst vorgeben, mehr dazu weiter unten unter "Benutzer(vor)einstellungen".

1.1.1.4. Quotas

Den Benutzern und Gruppen wird jeweils ein maximaler Speicherplatzverbrauch zugeordnet damit das Gesamtsystem durch Einzelne und Gruppen möglichst nicht in mitleidenschaft gezogen werden kann. Empfohlen wird getrennte Dateisysteme für /home und /group zu verwenden. Für näheres siehe quota.

1.1.1.5. Gruppenverzeichnisse

Projektgruppen bekommen eigene Verzeichnisse für ihre gemeinsamen Daten. Auch aus quotaerwägungen kann es sinnvoll sein Gruppenverzeichnisse auf ein anderes Dateisystem zu legen. Und zwar falls hier andere/keine Benutzerquotas wie unter /home gelten sollen. Zum Beispiel wenn einzelne Benutzer als Gruppenmitglied im Gruppenverzeichnis z.B. mehr Daten speichern können sollen als sie es als User unter /home dürften. (z.B. einige Gigabyte Messdaten, Videoaufnahmen, etc.)

Beispiele wie ein Gruppenverzeichnis beim Anlegen einer Gruppe standardmäßig erstellt werden könnte:

/group/penguin-priv             root    penguin         drwxrws---      (privates Gruppenverzeichnis der Pinguine)
/group/penguin-pub              root    penguin         drwxrwsr-x      (öffentlichtes Gruppenverzeichnis der Pinguine)

1.1.1.6. Zu Beachten

• Über NFS gemountete Dateisysteme unterstützten z.Z. nur mit einem Patch mehr als 16 Guppenmitgliedschaften eines Benutzers. (2004-03)

1.2. Diskussion

* Datenaustauschverzeichnisse gehören nicht ins home

• Das ist eine Überlegung wert, welche Gründe lassen sich hier anführen?

* ich möchte mir mein home nicht zumüllen lassen, außerdem muss dann home mindestens begehbar sein.

• Müll kann sich höchstens in /incoming ansammeln und zählt zur quota des Erstellers sofern Userquotas nicht vorschnell als nicht nötig verabschiedet werden sondern korrekt eingerichtet sind. Die Gruppe einer Datei wird auf die private Gruppe von /incoming gesetzt, damit nachträgliches löschen/verbessern nicht mehr möglich ist.

* damit kann jemand einen "DoS"-Angriff auf deine quota machen

• Nicht wenn Gruppen- und Benutzerquotas korrekt eingesetzt werden.

• Bedenke bitte /private und /public sind keine Austauschverzeichnisse sondern benutzbare Vorlagen und eine selbst für Neulinge triviale Möglichkeit den Zugiff zu steuern. Incoming braucht man sicherlich nur für einige Fälle/Benutzer. Doch wie gibt man nur bei einem ganz bestimmten User seine Arbeit ab?
  • Mail? Name im eigenen Home bekanntgeben, z.b. /home/tux/diese-datei-ist-nur-für-tuxine
• Wenn du selbst das begehen ausgeschließen möchtest?. Deswegen scheint mir das auch recht praxisfern. Mail wolte ich gerade nicht. Z.B. wegen großen Dateien und mehr potentiell mehr Fehleransatzpunkte. Außerdem müßten Herkunft und Fertigstellungszeit dann extra und komplizierter überprüfbar gemacht werden etc.

1.3. Lösung für abgeschottete Benutzer (ISP-Fall)

Verzeichnisse für den Webserver werden außerhalb des home abgelegt und per Symbolischem link aus dem Homeverzeichnis erreicht. Alles andere im System könnte für die Benutzer nicht einsehbar gemacht werden. (non-solution by obscurity)

• /home                           root    staff   drwxr-x--x
  /home/tux                               tux     staff   drwxr-x---
  
  /home/tux/public_html   root    root    lrwxrwxrwx      -> /srv/www/$USER
  /srv/www                                root    httpd   drwxr-x--x
  /srv/www/tux                    tux     httpd   drwxr-x---

2. Benutzer(vor)einstellungen

Neben dem Regeln der Zugriffsrechte von Benutzern sollten auch verschiedene Umgebungsvariablen und Einstellungen an die Bedürnisse der Benutzer angepasst werden. Dies kann entweder vom Systemadministrator oder in einigen bereichen bei Bedarf auch durch die Benutzer selbst erfolgen.

Zur Verwaltung von Benutzereinstellungen wird hier das Vorhalten von vernünftigen systemweiten Konfigurationen unter /etc ganz allgemein gezählt. Dateivorgaben beim anlegen neuer Benutzer (/etc/skel) oder direkte Anpassungen der Konfigurationsdateien unter /home sollten generell vermieden werden da sie später schlecht und nicht immer konfliktfrei zu warten sind. Wenn nicht anders möglich, ist es immer vorzuziehen mit /etc/skel nur einen symbolischen Link auf eine zentrale Konfigurationsdatei unter /etc vorzugeben anstatt Kopien zu verteilen.

In der Regel gibt es jedoch für jede Einstellung auch eine zentrale Konfigurationsvorgabe in /etc die von den Benutzern dann ggf. durch speichern anderslautender Einstellungen in ihrem Homeverzeichnis angepasst werden können. Möchte man nun aber für verschiedene Benutzergruppen unterschiedlich angepasste Voreinstellungen bereithalten gibt es mehrere Möglichkeiten:

• Root-Skripte die über alle Benutzer itterieren und überall die Einstellungen anpassen/ändern. (nicht zu empfehlen)

• Auswahl von verschiedenen "/etc/skell.<group>" Vorlageverzeichnissen beim Anlegen von Benutzern die Symlinks auf angepasste zentrale Konfigurationsvarianten z.B unter /etc/groupdefaults/<group>/ beinhalten. (mit z.B. ~/Desktop als Link in ein Gruppenverzeichnis ist dieser Trick auch für gemeinsame Benutzerdaten verwendbar)

• Gruppenspeziefische Anpassungen in der zentralen Konfiguration unterstützen. Bei Konfigurationsdateien die selbst kleine Shellskripte sind lassen sich evtl. Verzweigungen einbauen und unterschiedliche Dateien auswerten. Manche Programme bieten solche Funktionalität schon von sich aus, z.B. MTAs, Datenbanken oder die (netgroupbasierte) TCP-Wrapper Konfiguration. Die prinzipielle Idee ist (evtl. in verschiedenen Dateien oder Verzeichnissen) unterschiedliche Konfigurationen bereitzuhalten und dann (evtl. wieder in einer extra Datei) eine eigene Gruppenzuordnung zu machen, oder dafür einfach z.B auf /etc/group zu verweisen.

Ein wichtiges Anwendungsgebiet wäre z.B. die Anpassung von Menüstrukturen in einer Hierachie verschiedener Ebenen:

- Distributionsvorgaben (von upstream übernommen oder angepasst, unter /usr/share ?) - Zentrale Systemvorgaben (Netwerkweite Anpassung an Einsatzverhälnisse) - Zentrale Benutzergruppenvorgaben - Benutzerspezifische Anpassungen (unter /home)

Die Freedesktop.org Menü-Specs sehen dafür z.B. per-user bzw. per-group files vor: (Menü-Bearbeitung)

3. Unix Zugriffskontrolle richtig einsetzen

Bei Zugriffsverweigerungen durch den Kernel ist es Sache des User Interfaces eine aussagekräftige Rückmeldung zu geben, nicht des gesperrten Programms, Hardware oder Datenverzeichnis. Komandozeilenshells tun dies in der Regel korrekt, Grafische Oberflächen und Tools wie z.B. KDE, Gnome, Konqueror, etc. tun dies leider oft noch nicht. Dabei könnten diese z.B. sogar anbieten nach Passworteingabe weiterzuverfahren (su, sudo GUIs)

Sowohl Gnome als auch KDE unterstützen das schnelle komplette wechseln des aktiven Benutzers an einem Bilschirm mit mehreren X Servern auf weiteren virtuellen Konsolen.

In KDE kann in .desktop Dateien festgelegt werden als welcher Benutzer ein Programm gestartet werden soll. Eine "Rechts-Klick - Starten als ..." Funktion fehlt noch.

Weitere Entwicklungen: gdmflexiserver, xnest (Privacy Thread auf xdg-list und gnome-devel-list)

3.1. Zugriff auf Programme vs. Hardware und Daten

Nur in wenigen Fällen ist es wirklich nötig den Zugriff auf die Programme selbst zu beschränken (evtl. bei Spielen etc.). In diesen Fällen müssen die Programme selbst nur für eine bestimmte Benutzergruppe lesbar und startbar gemacht werden.

So wie Unix Systeme standardmäßig konfiguriert sind ist es jedoch nicht so einfach neuen Benutzer erstmal nur eine kleine beschränkte Anzahl von Programmen zu erlauben, und alles andere zu verbieten. Alle nicht erlaubten Programme müssten erst nur von einer "nicht-neuer-Benutzer" Gruppe lese und startbar gemacht werden, und alle anderen Benutzer müssten Mitglied dieser Gruppe sein um das System wie gewohnt weiterbenutzen zu können. (Andere "sandboxing" Möglichkeit: chroot Umgebungen oder Sicherheitserweiterungen wie SELinux)

In den meisten Fällen braucht man aber eigentlich nur den Zugriff auf die Daten/Hardware die das Programm verwendet zu beschränken, sprich nur für eine bestimmte Gruppe erlauben, und nicht den Zugriff auf das Werkzeug selbst einschränken. Bei einer Finanzverwaltung wie GnuCash zum Beispiel brauchen nur die Daten in einem Gruppenverzeichnis (s.o) abgespeichert zu werden um sie vor unbefugten Zugriff zu schützen. Eine weitergehende feinere Steuerung welche Gruppenmitglieder welche einzelnen Teile eines gemeinsamen Datenbestandes einsehen und bearbeiten können dürfen, muß in der Regel durch die Anwendung selbst gesteuert werden, oder kann durch unterschiedliche Zugriffsrechte auf eine Datenbank realisiert werden (sofern die Anwendung auf ein entsprechendes Datenbankserverprogramm zurückgreift. Was für Mehrbenutzerprogramme prinzipiell sinnvoll ist.

3.2. Kein direkter Zugriff, aber mittelbarer Zugriff über ein SUID/SGID Programm

Ein Beispiel hierfür ist die Gruppe "games". Dieser gehört kein Benutzer an, stattdessen können die Spiele "set-group-id games" gesetzt werden, so dass die Spiele systemweite Highscores abspeichern können, aber Benutzer diese nicht direkt manipulieren können.

SUID-root Progamme werden als schlechte Lösung angesehen, da Progammfehler das ganze System gefährden!

3.3. sudo

Damit kann man bestimmten Benutzern einzelne Zugriffe erlauben die mehr Rechte erfordern ohne ihnen das root Passwort geben zu müssen. man sudo

4. Welche Vorteile bringen ACLs? Wann sind sie wirklich nötig?

ACLs sind im Rahmen der Möglichkeiten von Unix Dateirechten rückwärtskompatibel.

Erlauben ACLs Blacklists also Listen von Benutzern oder Gruppen denen der Zugriff verwehrt wird?