Dämonische Tricks

Wo sind die Befehle?

Ein bisschen hier geschaut, ein bisschen dort – wer bislang unter Linux die Bash als Kommandozeilen-Shell gewohnt war, flucht unter FreeBSD erst einmal, wenn die gewohnte zweimalige Betätigung der [Tab]-Taste keineswegs alle an dieser Stelle möglichen Datei- oder Programmnamen auflistet. Nur ein einmaliges [Tab], sofern bereits ein eindeutiger Namensanfang in der Shell steht, sorgt bei root für eine vernünftige Dateinamenserweiterung. Die unprivilegierte Benutzerin pjung malt hingegen fleißig Tabulatorzeichen auf die Kommandozeile.

Der Grund ist mit einem Blick in die Passwortdatei /etc/passwd leicht zu ersehen:

root :0:0:Charlie &:/root:/bin/csh
[…]
pjung :1002:1003:Patricia Jung:/home/pjung:/bin/sh

Weder root noch pjung haben die Bash als Login-Shell; letztere Benutzerin vor allem deshalb nicht, weil sysinstall beim Anlegen neuer User im Menüpunkt Configure / User Management / User einfach keine Möglichkeit bietet, Login-Shells auszuwählen, deren Pfad man nicht kennt (Abbildung 5).

Abbildung 5: Anlegen neuer User mit sysinstall

Dieses Problem haben wir auch, wenn wir den Shell-Eintrag in der /etc/passwd verändern wollen. Ein Tool sollte uns jedoch zur Seite stehen, wenn wir nach der ausführbaren Datei bash fahnden. Sein Name: locate. Dumm nur, dass locate bash das System zu folgender Ausrede veranlasst:

locate: database too small: /var/db/locate.database

Ein Blick auf die locate-Datenbank-Datei zeigt, wie locate zu dieser Behauptung kommt:

$ ls -al /var/db/locate.database
-rw-r--r--  1 nobody wheel  0 Aug 14 21:21 /var/db/locate.database

Ganze null Byte ist einfach immer zu klein … Aus Linux-Erfahrung wissen wir, dass das Kommando updatedb für die Erstellung der locateschen Datenbasis verantwortlich zeichnet. Doch da beißt sich die Katze in den Schwanz: Wie sollen wir updatedb finden, wenn ein Aufruf des Kommandos als root

# updatedb
updatedb: Command not found

nur die misslaunige Antwort der Shell hervorruft, dass updatedb nicht im Suchpfad enthalten ist? locate kann uns den Ort des Befehls aus guten Gründen nicht verraten. Also bleibt der pragmatische Griff zur Manpage (Listing 1).

$ man locate
[…]
FILES
[…]
   /usr/libexec/locate.updatedb     Script to update the locate database
   /etc/periodic/weekly/310.locate  Script that starts the database rebuild
[…]

Et voilà – dann ruft root eben nicht updatedb, sondern das Skript zum Generieren der Datenbank mit

/usr/libexec/locate.updatedb &

auf, und nach einer Weile mag locate Antworten geben – ein paar zuviele vielleicht, die sich zum seitenweisen Anzeigen wie unter Linux mit einer Pipe an less verfüttern lassen: locate /bash |less. Allerdings hätten wir die richtige Antwort, bash sei unter /usr/local/bin/bash zu finden, auch einfacher haben können: Zum einen mit which bash (/usr/local/bin ist Bestandteil des Suchpfades), zum anderen mit man shells: Diese Manpage verrät, dass die Datei /etc/shells (übrigens wie unter Linux) alle auf dem System installierten Shells mit Pfadangabe auflistet.

Solche hilfreichen Manpages gibt es übrigens mehrere: Wer der Login-Meldung einen genaueren Blick schenkt, wird zum Beispiel auf man hier aufmerksam, das einen lesenswerten Spaziergang durch den FreeBSD-Dateibaum unternimmt.

Der Master-Plan

Wenn root jetzt allerdings frohgemut zum Editor greift und in der /etc/passwd den Shell-Eintrag /bin/sh bei pjung in /usr/local/bin/bash ändert, hat die Rechnung ohne den kleinen Dämon gemacht. Loggt sich pjung erneut ein, funktioniert [Tab] immer noch nicht wie in der Bash und die Pfeiltasten für die History auch nicht.

man 5 passwd (in Sektion 5 befinden sich die Manpages zu Dateien) klärt auf: Wie mittlerweile auch unter Linux gängig, benutzt FreeBSD ein Shadow-Passwort-System: /etc/passwd enthält anstelle der verschlüsselten Passwörter ein *; diese sind in eine nur root zugängliche Schatten-Passwort-Datei ausgelagert. Während die /etc/shadow unter Linux jedoch komplett anders aufgebaut ist als /etc/passwd und außer dem User-Namen keine Daten daraus wiederholt, speichert die FreeBSD-Master-Passwort-Datei /etc/master.passwd auch alle aus /etc/passwd ersichtlichen Daten noch einmal.

Maßgebend für ein Login sind die Daten aus /etc/master.passwd. Doch selbst wenn root diese per Editor ändert, passiert noch nichts: Da das Parsen einer Textdatei vergleichsweise ressourcenintensiv ist, greift das login-Programm auf eine binäre Version der Master-Datei zu. Solange die nicht auch auf dem aktuellen Stand ist, sieht es schlecht aus für pjung.

Die passwd-Manpage legt im Abschnitt SEE ALSO immerhin den Gedanken nahe, einmal das Kommando pwd_mkdb ("passwd_makedatabase") unter die Lupe zu nehmen. Tatsächlich kann root mit

pwd_mkdb -u pjung /etc/master.passwd

gezielt den veränderten Eintrag für pjung aus /etc/master.passwd in den binären Datenbankdateien /etc/spwd.db (nur für root zugänglich, enthält die verschlüsselten Passwörter) und /etc/pwd.db (ohne Passwort, für alle lesbar) aktualisieren.

Zwei Dateien editieren und dann noch ein kryptisches Kommando aufrufen? Da greift jede Sysadmine gerne zu bereitgestellten Helfer-Tools: FreeBSD kennt vipw, ein Werkzeug, von dem in der Linux-Welt zumindest Debian-Nutzer(inne)n schon einmal gehört haben dürfen. In der FreeBSD-Version lädt es die Master-Passwort-Datei in den Editor vi (daher der Name) und erledigt die übrigen Aktionen automatisch. Will die Admine lieber ee benutzen, sagt sie (sofern sie mit der Default-C-Shell arbeitet) vor dem vipw-Aufruf einfach setenv EDITOR ee.