16.3. Format der PAM Konfigurationsdatei

16.3.1. Modul-Schnittstellen

Es gibt vier Typen von Modul-Schnittstellen, welche den unterschiedlichen Aspekten des Authentifizierungsprozesses entsprechen:

• auth — Diese Modulschnittstelle authentifiziert den User. Zum Beispiel erfragt und �berpr�ft diese das Passwort. Module mit dieser Schnittstelle k�nnen ebenso Berechtigungsmerkmale festlegen, wie z.B. Mitgliedschaft in einer Gruppe oder Kerberos-Tickets.

• account — Diese Modulschnittstelle stellt sicher, dass der Zugriff erlaubt ist. Zum Beispiel k�nnen sie pr�fen, ob der Account abgelaufen ist, oder ob der Benutzer zur Anmeldung um diese Uhrzeit zugelassen ist.

• password — Diese Modulschnittstelle wird zur Einstellung des Passworts verwendet.

• session — Diese Modulschnittstelle wird, nachdem der Benutzer authentifiziert wurde, dazu verwendet, dessen Session zu verwalten. Das Modul kann auch zus�tzliche, f�r den Zugriff ben�tigte Tasks durchf�hren, wie beispielsweise das Mounten des Home-Verzeichnisses des Benutzers oder die Aktivierung seiner Mailbox.

	Anmerkung
	Ein einzelnes Modul kann jeglichen, oder alle der o.g. Modul-Schnittstellen ansprechen. Zum Beispiel pam_unix.so besitzt Komponenten, die alle vier Modularten ansprechen.

In einer PAM Konfigurationsdatei wird als Erstes die Modul-Schnittstelle bestimmt. Eine typische Zeile in einer Konfiguration k�nnte wie folgt aussehen:

auth      required  pam_unix.so

Dies weist PAM an, die auth-Schnittstelle des pam_unix.so Moduls zu verwenden.

auth       required     pam_nologin.so
auth       required     pam_securetty.so
auth       required     pam_env.so
auth       sufficient   pam_rhosts_auth.so
auth       required     pam_stack.so service=system-auth

16.3.2. Steuer-Flags

Alle PAM-Module erstellen bei einer �berpr�fung Fehler- oder Erfolgsmeldungen. Die Steuer-Flags geben PAM an, was mit diesen Ergebnissen geschehen soll. W�hrend Module in einer bestimmten Reihenfolge gestapelt werden k�nnen, k�nnen Sie mit den Steuer-Flags einstellen, wie wichtig der Erfolg oder das Fehlschlagen des entsprechenden Moduls f�r die Authentifizierung des gesamten Service ist.

Es gibt vier vordefinierte Steuer-Flags:

• required — Solche Module m�ssen erfolgreich �berpr�ft werden, bevor die Authentifizierung erfolgen kann. Wenn bei einem required Modul Fehler auftreten, wird der Benutzer dar�ber informiert, sobald auch alle anderen Module, welche die gleiche Schnittstelle referenzieren �berpr�ft wurden.

• requisite — Solche Module m�ssen ebenfalls �berpr�ft werden, bevor die Authentifizierung erfolgreich sein kann. Wenn bei einem requisite Modul Fehler auftreten, wird der Benutzer hier�ber sofort informiert. Diese Mitteilung zeigt das erste fehlerhafte required oder requisite Modul an.

• sufficient — Bei solchen Modulen werden Fehler ignoriert. Wenn ein sufficient Modul jedoch erfolgreich �berpr�ft wurde, und kein required Modul fehlschl�gt, werden keine weiteren �berpr�fungen dieser Modul-Schnittstelle ben�tigt und diese wird erfolgreich authentifiziert.

• optional — Solche Module sind f�r die erfolgreiche oder fehlgeschlagene Authentifizierung dieser Modul-Schnittstelle nicht von Bedeutung. Diese werden nur dann wichtig, wenn kein anderes Modul dieser Modul-Schnittstelle erfolgreich war oder fehlgeschlagen ist.

	Wichtig
	Die Reihenfolge in welcher required Module aufgerufen werden spielt keine Rolle. Bei den Steuer-Flags sufficient und requisite ist die Reihenfolge allerdings wichtig.

Eine neuere Steuer-Flag Syntax mit immer mehr Kontrollm�glichkeiten steht nun f�r PAM zur Verf�gung. Mehr Informationen �ber diese neue Syntax finden Sie in den PAM-Dokumentationen im Verzeichnis /usr/share/doc/pam-version-number/ (wobei <version-number> die Versionsnummer von PAM ist).

16.3.3. Modulname

Der Modulname liefert PAM den Namen des Pluggable Moduls, das die angegebene Modulschnittstelle enth�lt. Unter �lteren Versionen von Red Hat Enterprise Linux wurde der vollst�ndige Pfad zum Modul in der PAM-Konfigurationsdatei angegeben, wie z.B. /lib/security/pam_stack.so. Seit dem Aufkommen von Multilib-Systemen, die 64-bit PAM Module im Verzeichnis /lib64/security/ speichern, wird der Verzeichnisname jedoch weggelassen, da die Applikation zur richtigen Version von libpam gelinkt ist, welche die richtige Version des Moduls feststellen kann.

16.3.4. Modul-Argumente

PAM verwendet Argumente, um w�hrend der Authentifizierung Informationen �ber eine bestimmte Modul-Schnittstelle einem "Pluggable Module" zu �bermitteln.

Zum Beispiel verwendet das Modul pam_userdb.so versteckte Dateien aus der Berkeley DB-Datei, um den Benutzer zu authentifizieren. Berkeley DB ist eine in vielen Anwendungen eingebundenes Open-Source Datenbank-System. Das Modul verwendet ein db Argument, welches die von Berkeley DB f�r den angeforderten Service zu verwendende Datenbank angibt.

Eine typische pam_userdb.so Zeile in einer PAM- Konfigurationsdatei sieht wie folgt aus:

auth      required  pam_userdb.so db=<path-to-file>

Im vorangegangenen Beispiel ersetzen Sie <path-to-file> mit dem vollst�ndigen Pfad der Berkeley DB Datenbank-Datei.

Ung�ltige Argumente werden ignoriert und wirken sich auch nicht auf den Erfolg oder Misserfolg eines PAM-Moduls aus. Wenn ein ung�ltiges Argument auftaucht, erscheint jedoch normalerweise eine Fehlermeldung in der Datei /var/log/messages.