Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Rerenzhandbuch- Format der PAM Konfigurationsdatei

16.3. Format der PAM Konfigurationsdatei

Jede PAM Konfigurationsdatei enth�lt eine Gruppe von Anweisungen, welche wie folgt formattiert sind:

<module interface>  <control flag>   <module name>   <module arguments>

Jedes dieser Elemente ist in den folgenden Abschnitten erkl�rt.

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.

AnmerkungAnmerkung
 

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.

16.3.1.1. Modul-Schnittstellen stapeln

Anweisungen der Modul-Schnittstellen k�nnen gestapelt werden, so dass mehrere Module zu einem Zweck verwendet werden k�nnen. Deshalb ist die Reihenfolge in der die Module aufgelistet werden f�r den Authentifikationsprozess sehr wichtig.

Das Stapeln macht es dem Administrator einfacher, zu erkennen, dass bereits einige Voraussetzungen erf�llt sind, bevor die Benutzerauthentifizierung stattgefunden hat. Zum Beispiel verwendet rlogin in der Regel f�nf gestapelte auth Module, wie in der PAM-Konfigurations- datei zu sehen:

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

Bevor rlogin ausgef�hrt werden kann, stellt PAM fest, dass die Datei /etc/nologin nicht existiert, dass niemand versucht, sich von einem Remote-Rechner �ber eine unverschl�sselte Netzwerkverbindung als Root anzumelden und dass alle Umgebungsvariablen geladen werden k�nnen. Wenn die rhosts -Authentifizierung erfolgreich ist, kann die Verbindung zugelassen werden. Ist die Authentifizierung nicht erfolgreich, wird zur Standardauthentifizierung mit Passwort �bergegangen.

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.

WichtigWichtig
 

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire