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

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS 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