PAM凭证信息来源及认证校验机制的技术咨询

Hey there! Let's break down your questions about PAM credential handling clearly—since you already have a grasp of PAM APIs and /etc/pam.d/ configurations, this should align with what you're already learning.

PAM doesn't rely on a single fixed source for credentials; it depends on your application's integration approach and the PAM modules you're using. Here are the most common scenarios:

• Directly from your application: If your app sends a username like "abc" and password "XXXXX" to PAM, it’s likely using pam_set_item() to populate PAM’s internal data items like PAM_USER (for the username) and PAM_AUTHTOK (for the password). This is exactly the workflow you described, where the app collects credentials first and passes them directly to PAM.
• PAM modules request credentials via your app: If your app doesn’t provide credentials upfront, some modules (like the default pam_unix) will trigger a dialogue with the user through the pam_conv callback function your app implements. For example, the module might ask your app to prompt the user for a password, and your app then passes that input back to the module as the credential.
• External credential stores: When using modules like pam_ldap, pam_winbind, or pam_radius, PAM doesn’t store or collect credentials locally. Instead, the module forwards the credentials to an external service (LDAP server, Active Directory, RADIUS server) that holds and validates the actual credential data.

The validation flow strictly follows the rules defined in your target PAM service’s config file (in /etc/pam.d/), and works step-by-step like this:

1. Initialize the PAM context: Your app calls pam_start() to link to a specific PAM service (e.g., "login" or your custom service name), which loads the corresponding config rules.
2. Trigger authentication: When your app calls pam_authenticate(), PAM executes the modules listed in the auth section of the service config in the order they’re written.
3. Module-specific validation:
   • For local modules like pam_unix: The module retrieves the stored hashed password for the user (from /etc/shadow, or NIS if configured). It then hashes the provided plaintext password using the same algorithm (e.g., SHA-512) and compares the two hashes. If they match, the module returns success.
   • For external modules like pam_ldap: The module sends the username and password to the configured LDAP server. The server checks if the credentials match its user directory and sends a success/failure response back to the PAM module.
4. Combine module results: PAM uses the control flags in the config (like required, sufficient, requisite) to determine the overall outcome:
   • required: The module must succeed; if it fails, authentication fails (but PAM will run all other required modules first).
   • sufficient: If this module succeeds, PAM skips remaining modules and marks authentication as successful.
   • requisite: If this module fails, PAM immediately stops and returns failure.
5. Return result to app: Finally, pam_authenticate() returns a success or failure code to your application, which can then act accordingly (e.g., grant access or show an error).

内容的提问来源于stack exchange，提问作者bubu0321