Geteilte Dateien

Großrechner bieten diese Möglichkeit schon lange: Eine Reihe von Nutzern greifen mit unterschiedlichen Rechten auf einzelne Dateiobjekte zu. Ein Beispiel dafür ist die Implementation RACF für das Betriebsystem z/OS. Diese findet auf Großrechnern von IBM Verwendung, die manch einer vielleicht aus der Werbung kennt: "Wo sind alle unsere Server hin?"

Seit einiger Zeit gibt es Patches für den Linux-Kernel, mit denen Sie einem aktuellen Kernel der Reihe 2.4 diese Fähigkeiten ebenfalls beibringen können. Doch bevor wir mehrere Nutzer auf unsere Dateien loslassen, erstmal ein kleiner Überblick über die klassische Vergabe von Zugriffrechten.

Zugriffsregeln klassisch

Neben dem Zugriffsschutz auf das System selbst, also dem Login mit Passwort, überwacht des Betriebssystem den Zugriff auf die einzelnen Objekte (Dateien, Verzeichnisse und Geräte). Dafür besitzt jedes Objekt und jeder Prozess zwei verschiedene Attribute: einen Eigentümer und eine Gruppe.

Zudem gibt es für jedes Objekt noch Zugriffsrechte, die für den Eigentümer, die Gruppe und alle anderen Benutzer auf dem System separat gesetzt werden. Lassen Sie sich mit ls -l den Inhalt eines Verzeichnisses anzeigen, finden Sie dort die Zugriffsrechte in der ersten Spalte (Kasten 1).

Arbeiten Sie mit einer Datei, prüft Linux jedesmal, wie ein von Ihnen gestartetes Programm zugreifen darf. Wichtig ist dabei, dass die benötigten Zugriffsrechte vorhanden sind. Zusätzlich müssen Sie berücksichtigen, dass der Prozess nicht nur Ihre Nutzer- und Gruppen-ID trägt, sondern zudem Informationen über die effective user ID und die effective group id berücksichtigt werden.

Der "effektive Nutzer" (effective user) leitet sich in der Regel aus Ihrer Benutzer-ID ab, wenn Sie ein Programm starten. Bei der Gruppe verhält es sich genauso. Ruft dieses Programm ein weiteres auf, so erbt dieses wiederum Nutzer und Gruppe vom aufrufenden Prozess. Der effektive Nutzer ist demnach identisch mit dem realen Nutzer.

Der effektive Nutzer ändert sich, wenn beim aufgerufenen Programm das so genannte S-Bit gesetzt hat. In diesem Fall erbt der Prozess nicht Nutzer und Gruppe des Vaterprozesses, sondern erhält den Nutzer, der als Besitzer des Binaries im Dateisystem eingetragen ist. Um dann immer noch herausfinden zu können, wer den Prozess eigentlich gestartet hat, gibt es neben der Effective User ID auch eine Real User ID, die über den wirklichen Prozessbesitzer informiert. Die folgenden Zeilen zeigen ein Beispiel dafür.

root@maus:# cp /bin/sleep /bin/rootsleep
root@maus:# chmod u+s /bin/rootsleep
root@maus:# su volker -c "rootsleep 25" &
root@maus:# /bin/ps -aeo pid,euser,ruser,command|grep fdisk
12887 root     volker   rootsleep 25

Das Dienstprogramm passwd

Ein gutes Beispiel für die Verwendung des S-Bits ist das Programm passwd. In einem Linux-System liegen alle verschlüsselten Passwörter der Nutzer in der Datei /etc/passwd. Aus Sicherheitsgründen ist diese Datei natürlich so geschützt, dass nur der Administrator Schreibrechte auf diese Datei besitzt.

Dennoch muss der Nutzer sein Passwort ändern können. Dies ermöglicht ihm das Programm passwd, bei dem das S-Bit für den Eigentümer gesetzt ist. Manchen Distributoren setzen es auch bei der Gruppe. Ist es gesetzt, erscheint statt dem x ein s, wenn Sie sich eine solche ausführbare Datei mit ls -l ansehen:

volker@maus:~> ls -l /usr/bin/passwd
-rwsr-xr-x    1 root  shadow  27604 Sep 20  2001 /usr/bin/passwd
volker@maus:~> ls -l /etc/passwd
-rw-r--r--    1 root  root     2070 Feb 10  2002 /etc/passwd

Jeder Anwender darf das Programm passwd aufrufen. Zusätzlich ist das S-Bit für den Eigentümer gesetzt. Damit erhält beim Programmstart der Prozess den effektiven Nutzer root. Mit diesem effektiven Nutzer darf nun jeder die Datei /etc/passwd, die ja für den User root schreibbar ist, andern und somit sein Passwort neu setzen. Dabei achtet das Programm passwd darauf, dass der Nutzer dies wirklich nur für seinen eigenes Eintrag in der Datei macht.