!!!Besonderheiten bei mehreren Benutzern

Da wir in der LUG wohl endlich unseren UML-Server aufgesetzt haben und da ich bei mir in der Firma auch sowas wie eine Benutzerverwaltung aufbauen möchte, habe ich diese Seite angefangen, um Besonderheiten zu sammeln, die es in Systemen mit mehreren Benutzern gibt. Ich gehe dabei von einem System aus, auf dem mehrere Leute arbeiten. Manche davon arbeiten gemeinsam an Projekten, manche haben Freunde, denen Sie vertrauen und manche sind mit Vorsicht zu geniessen (also wie im richtigen Leben).

!!Permissions

Permissions sind die Zugriffsrechte auf einzelne Dateien. Eine Einführung gibt es z.B. in der [Debian Referenz|http://www.us.debian.org/doc/manuals/reference/ch-tutorial.de.html#s-file-perm]. Hier möchte ich aber nun einige zusätzliche Gedanken niederschreiben, was man an der Debian-Grundkonfiguration verbessern kann. Ich lege meine Gedankengänge hier auf und hoffe auf eine rege Diskussion.

!!Grundlegende Geheimhaltung

Ich bin der Meinung, daß es keine gute Idee ist, wenn grundsätzlich alle User alle Dateien lesen können. Deshalb sollte man im Gegensatz zur Debian-Grundeinstellung die umask für "Others" (also die letzte Ziffer) mindestens auf 6 (nicht lesen und schreiben), besser auf 7 (auch nicht ausführen bzw. auf Verzeichnisse nicht zugreifen) setzen:
{{{
 umask xxx7
}}}

!!Gruppen und Freunde

Grundsätzlich mal ist eine Gruppe dazu da, Leute zu kennzeichnen, die ein gemeinsames Projekt haben. Aber was mache ich mit Dateien, die eigentlich nur privat von mir sind? Diese bekommen die Standardgruppe des Benutzers zugewiesen. Historisch gibt es hier nun zwei Systeme, welche Gruppe das ist. Manche Systeme erzeugen eine Gruppe, z.B. users, in die alle Benutzer kommen und die immer die Standardgruppe ist. Modernere Systeme (wie Debian) erzeugen für jeden Benutzer benutzer eine eigene Gruppe benutzer. Bei der älteren Methode war eigentlich kein praktischer Unterschied zwischen den Group- und den Others-Permissions einer Datei. Es waren eh alle anderen Benutzer in der Gruppe (ausser den Systembenutzern). Die Permissions machten nicht soviel Sinn. Beim neueren System ist nun eigentlich kein Unterschied zwischen den User- und Group-Permissions.

Dies macht auf den ersten Blick genausowenig Sinn, hat aber einen entscheidenden Vorteil: Ich kann Leute in meine Gruppe aufnehmen und Ihnen so mein besonderes Vertrauen aussprechen. Sie sind meine "Freunde". Wofür dient das jetzt? Ein Freund kann jemand sein, der meine Arbeit im Zweifelsfall (bei Krankeit oder Urlaub) fortführen kann. Es kann auch mein Abteilungsleiter oder Chef sein, der an meine Arbeit jederzeit kommen muss (ohne direkt root zu sein).

Nach meinem Verständnis sollte so jemand im Gegensatz zum Debian-Standard auch Schreibrechte auf meine Dateien haben:
{{{
 umask xx0x
}}}

!!Projektgruppen

Im [Filesystem Hierarchy Standard|http://www.pathname.com/fhs/] konnte ich nichts darüber finden, wo man Gruppenverzeichnisse (d.h. Projektdaten) am besten anlegt. Einerseits liegen globale bewegliche Daten in /var (z.B. ein gemeinsames CVS-Repository), während die privaten Projekte von Usern ja bekanntlich in Unterverzeichnissen von /home liegen (Sourceforge benutzt z.B. /home/groups/...). Eine dritte Möglichkeit wäre, Projekte im Homeverzeichnis des Projektleiters anzulegen. Dann müssen alle Projektmitglieder allerdings Zugriffsrechte (x-Rechte) auf das Homeverzeichnis des Projektleiters haben. Haben sie gleichzeitig Leserechte, so können sie das Verzeichnis lesen, was IMO eigentlich nicht gewollt sein kann. Haben sie diese nicht, müssen sie sich "blind" das Unterverzeichnis suchen, was zwar möglich aber unelegant ist.

Aus diesem Grunde bevorzuge ich Projektverzeichnisse in /home/groups/....

Der Besitzer des Gruppenverzeichnisses kann der Projektleiter oder root sein. Da root sowieso die Systemgruppe anlegen muss, kann das am besten root sein.

In Projektverzeichnissen sollte man nun das Set-Group-Bit setzen: chmod g+s. Hierdurch bekommen alle hier von Gruppenmitgliedern angelegten Dateien dieselbe Gruppe. Hierin liegt noch ein Grund, warum die umask auf xx7x gesetzt sein sollte.

Das Sticky-Bit sollte bei diesen Verzeichnissen übrigens nicht gesetzt werden. Dadurch kann jedes Mitglied der Gruppe alle Gruppendateien löschen. Dies sollte in einer Projektgruppe wohl auch so sein.

Also erzeugt man Gruppenverzeichnisse am besten so:
{{{
 mkdir /home/groups/gruppenname
 chown root.gruppenname /home/groups/gruppenname
 chmod g+rwxs,o-rwx,-t /home/groups/gruppenname
}}}

!!umask

Zusammengefasst sollte die umask 0007 sein. Dies kann man in /etc/login.defs einstellen. Ein weiterer Eintrag (der IMHO nicht da sein sollte) findet sich in /etc/profile. Leider funktioniert das nicht unter kdm (obwohl auch das gehen sollte). Hier half nur die Installation des libpam-umask-Moduls und eine Zeile in der Datei /etc/pam.d/common-session:
{{{
 session optional pam_umask.so umask=007
}}}

!!dirmode

Nun ist noch zu überlegen, welche Permissions das Home-Verzeichnis von Benutzern haben sollte. Debian legt hier 0755 vor. Um einerseits meine "Freunde" zu bevorzugen und andererseits alle Fremden auszuschliessen, schlage ich besser 0770 vor. Konfigurieren kann man das im nachhinein mit chmod oder von vorneherein in /etc/addusers.conf.

[{Tag Linux}]