Im Linux-Magazin 07/10 stellte Sysadmin Charly einen Einzeiler vor. Der soll unmittelbar nach erfolgtem Login eine E-Mail an eine vordefinierte Adresse schicken – es handelt sich also um ein simples Intrusion-Detection-System [1]. Damit der Einzeiler für alle Anwender des Systems zur Verfügung steht, fügte Charly ihn in die systemweite »bashrc« ein.

Obgleich das Skript selbst korrekt war, hatte der Eintrag gewisse unangenehme Nebenwirkungen. Auch Hersteller proprietärer Software empfehlen in ihren Installationsdokumentationen gern einmal die falschen Konfigurationsdateien, deren Effekt erst später sichtbar wird.

Bash ist nicht gleich Bash

Die Bash lässt sich auf zwei Arten aufrufen, als interaktive und als Login-Shell, wobei das System in den meisten Fällen die Wahl trifft. Das wirft die Frage auf, wann das System wie entscheidet und worin der Unterschied besteht.

Eine Bash, die das System als Login-Shell startet, soll die Benutzerumgebung initialisieren. Dabei definiert die Shell einige Variablen und Aliases und mitunter auch – via »umask« – die automatischen Zugriffsrechte für neu erstellte Dateien. Meldet sich ein Nutzer an, ruft das System in der Regel eine Login-Shell auf und die Bash führt einige Schritte zur Initialisierung der Benutzerumgebung durch.

Zunächst arbeitet sie die Datei »/etc/profile« ab. Im Anschluss klappert sie das Homeverzeichnis der Reihenfolge nach auf der Suche nach den Dateien »~/.bash_profile«, »~/.bash_ login« und »~/.profile« ab und verarbeitet den zuerst angetroffenen Kandidaten. Existieren mehrere dieser Dateien – etwa eine »~/.bash_profile« und eine »~/.profile« – liest die Shell nur die Datei »~/.bash_profile« ein und ignoriert die zweite. Meldet sich ein Anwender vom System ab, beendet er die Login-Shell, die sich mit Hilfe der Datei »~/.bash_ logout« verabschiedet.

Ob er momentan mit einer Login-Shell arbeitet, findet der Anwender durch »echo $0« heraus. Steht in der Ausgabe ein »-bash«, weist das auf eine Login-Shell hin, andernfalls auf eine interaktive. Will der Anwender zu Testzwecken eine Login-Shell ausführen, ohne sich dauernd ab- und anzumelden, erledigt er das über den Aufruf »bash -l«.

Die interaktive Shell initialisiert ihre Systemumgebung nicht selbst, sie geht davon aus, dass der übergeordnete Prozess bereits eine Systemumgebung geschaffen hat und diese vererbt. Jede Shell, die das System nicht als Login aufruft, ist eine interaktive Shell. Der Admin startet sie, indem er ein grafisches Terminal aufruft oder durch die Eingabe von »bash« in eine interaktive Shell gelangt.

Diese liest – zumindest in Version 4 der Bash – nach dem Start die Dateien »/etc/bash.bashrc« oder »/etc/bashrc« und dann die ».bashrc« im Homeverzeichnis ein. Ältere Versionen der Bash kümmern sich hingegen nur um die Datei »~/.bashrc«, die dann ihrerseits auf die Inhalte der Datei »/etc/bashrc« zugreift. Startup-Skripte für die interaktiven Shells legt man hauptsächlich an, weil die Shell keine Aliases vererbt.

Eskapaden

Die Distributoren tragen leider nicht dazu bei, die verworrene Situation (siehe Abbildung 1) zu entspannen. Im Allgemeinen kann der Anwender davon ausgehen, dass die beim Start einer Login-Shell eingelesene Datei »/etc/profile« auch die Datei »/etc/bash.bashrc« durchforstet. Durch diesen Umstand springt Charlys Einzeiler dem Tod noch von der Schippe (wenn auch nicht ohne Folgeschäden, doch dazu später).

Abbildung 1: Abhängig davon, ob die Bash als Login-Shell startet, führt sie eine Reihe von Skripten aus.

Inzwischen ist es bei den Distributionen auch Usus, dass sich die Datei »~/.profile« die »~/.bashrc« einverleibt. Noch weiter geht Open Suse, wo die »~/.bashrc« wiederum »~/.alias« einliest. Dort verwaltet der Anwender seine Aliases auf Wunsch gesondert.

Ebenfalls unter Open Suse verinnerlicht die Datei »/etc/profile« auch die Inhalte der Datei »/etc/profile.local«, womit der Admin seine Systemanpassungen vor dem nächsten Upgrade schützen will. Nicht zuletzt gibt es in jeder namhaften Distribution ein Verzeichnis namens »/etc/profile.d«. Die Shell liest die darin enthaltenen Skripte, die mit »*.sh« enden, ebenfalls ein.

Bourne-Shell-Kompatibilität

In der klassischen Bourne-Shell (»/bin/sh«) gab es für die Initialisierung der Benutzerumgebung nur die Dateien »/etc/profile« und »~/.profile«. Da die Bash rückwärtskompatibel zur Bourne-Shell ist, liest sie diese Dateien auch ein, wobei sie den oben erwähnten Regeln folgt. Da sich auch die zur Bourne- kompatible Korn-Shell auf diese Dateien stützt, ist es wichtig, dass ihre Inhalte kompatibel zur Bourne-Shell sind und keine Bash-Spezifika enthalten.

Jeder Admin hat schon mal ein Skript geschrieben, das beim interaktiven Aufruf tadellos funktioniert, beim Start über Cron aber nicht. Das liegt daran, dass Cron keine Login-Shell ausführt und so die Systemumgebung nicht initialisiert. Meist scheitert das Skript an der unvollständigen »PATH«-Variablen.

Startet der User ein Terminal aus der grafischen Benutzeroberfläche heraus, ruft Linux es nicht als Login-Shell auf, da er sich ja bereits beim Displaymanager angemeldet hat. Als resultierender Kollateralschaden würde auch Charlys Vorschlag in den Dateien »/etc/bashrc« oder »/etc/bash.bashrc« jedes Mal eine Nachricht per E-Mail verschicken, sobald ein Anwender innerhalb einer Benutzersitzung ein Terminal öffnet.

Einige Dokumentationen schlagen vor, Anwender sollen doch bei der Installation Einträge in den Dateien »~/.bash_profile« oder »~/.profile« vornehmen. Existieren diese Datei noch nicht, sollten sie aber umsichtig handeln: Legen sie die nicht vorhandene Datei »~/.bash_profile« an, hebeln sie dadurch eine eventuell vorhandene »~/.profile« aus – die Bash verarbeitet immer nur eine der Dateien. Erstellt er hingegen eine nicht vorhandene »~/.profile«, ignoriert die Bash diese Datei, wenn es bereits eine »~/.bash_profile« auf dem Rechner gibt.

Querschläger »pam_env«

Da hier Red Hat und Open Suse genau gegenläufig arbeiten, ist Vorsicht geboten. Kein Wunder, dass Admins oft auch nicht wissen, ob sie »su« mit oder ohne Minus aufrufen sollen. Kleiner Unterschied, große Wirkung: Ein »su -« führt eine Login-Shell aus, ein alleiniges »su« hingegen eine interaktive.

Wer als Admin schon einmal dem Ursprung der Systemumgebung auf der Spur war, hat sich vielleicht gewundert, warum das System Variablen setzt, die in der »/etc/profile« und verwandten Dateien nicht auftauchen. Eine mögliche Ursache kann das Plugable Authentication Module »pam_env« sein. Das erlaubt es dem Systemverwalter, allen Login-Shells vordefinierte Umgebungsvariablen mit auf den Weg zu geben. Da das System diese Variablen jedoch vor dem Ausführen der Bash-Startskripte setzt, überschreiben diese die Variablen wieder.

Wege nach Rom

Da die Distributionen in der Frage der berücksichtigten Startskripte sehr unterschiedliche Wege gehen, gibt es keine allgemein gültigen Regeln. Tabelle 1 enthält Empfehlungen für die Konfiguration von Login-Shells, Tabelle 2 solche für interaktive Shells. Beide setzen voraus, dass der Admin in Bezug auf die Startskripte keine Änderungen an der Standardkonfiguration vornimmt.

Dass die Bash potenziell sieben Dateien in das Starten und Beenden der Shell involviert, macht die Angelegenheit nicht einfacher. Auch nicht, dass jeder Distributor sein eigenes Süppchen kocht und weitere Dateien ins Spiel bringt. Möchte ein Admin dann nicht nur einen Eintrag hinzufügen, sondern einen bestehenden ändern oder entfernen, wächst sich das unter Umständen zur berühmten Suche nach der Nadel im Heuhaufen aus. Mit etwas Geduld lassen sich aber in beiden Fällen die richtigen Dateien aufspüren. (mg/kki)