[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: trouble stacking password modules



Steve Langasek wrote:

On Tue, Jan 14, 2003 at 11:03:56AM -0500, Joseph Konczal wrote:


There should also be more specific guidance in the module writers' guide, section 5.2, Use of syslog(3), on what specific information should be logged. The module producing a message to the user should be identified in the message, for ecample. It is confusing to see duplicate messages with slight variations from stacked modules without any indication of which module produced them.



This sounds useful for debugging only.


You're probably right. However, it just doesn't look right to get two notices that you are changing the password for "jck" and "user jck." It is not the kind of thing that will help win over an open-source skeptic. The program that uses pam to change a password knows that it is changing the password for a certain user, perhaps it should produce the "changing password for user ___" message once, if appropriate, instead of each password module showing its own variation. Similarly, if the programmer wants to explicitly tell the user that the password change succeeded, the program using pam should produce this message, not each module.



Try to interpret the following transcript.






-bash-2.05b$ passwd
Changing password for user jck.
Changing password for jck
(current) UNIX password:



First pass through the password stack, pam_cracklib does nothing, so
pam_unix prompts for the current password. This shows that
'try_first_pass' is working in this module.


But it only seems to work if PAM_OLDAUTHTOK is not set to an incorrect password.

[...]


password required /lib/security/pam_cracklib.so retry=3 type=UNIX_and_SMB debug
password required /lib/security/pam_unix.so nullok md5 use_authtok try_first_pass debug
password optional /lib/security/pam_smbpass.so nullok use_authtok try_first_pass debug



Recommendation:


password    requisite      pam_cracklib.so retry=3 type=UNIX_and_SMB debug
password    requisite      pam_unix.so nullok md5 use_authtok try_first_pass debug
password    optional       pam_smbpass.so nullok use_authtok try_first_pass debug

Your config above will return an error if either pam_cracklib or pam_unix
failed, but it wouldn't return the error until after the end of the stack
-- this leads to being able to change the password in spite of the
cracklib policy, and being able to change the smbpasswd in spite of a
pam_unix failure.


Thanks for the good advice. I derived my configuration from the RedHat default PAM configuration, which is similar to the examples at the end of section 6.6.3 of the Linux-PAM System Administrators' Guide, on pages 25 and 26. They all use "required" instead of "requisite." Fortunately, pam_cracklib apparently does not set PAM_AUTHTOK if the password fails the tests, so the other modules on the stack also failed:

Jan 14 14:13:11 zang passwd(pam_unix)[3377]: username [jck] obtained
Jan 14 14:13:14 zang PAM_smbpass[3377]: username [jck] obtained
Jan 14 14:13:14 zang PAM_smbpass[3377]: failed auth request by jck for service passwd as jck(999)
Jan 14 14:13:17 zang PAM-Cracklib[3377]: bad password: it is too short
Jan 14 14:13:21 zang last message repeated 2 times
Jan 14 14:13:21 zang passwd(pam_unix)[3377]: username [jck] obtained
Jan 14 14:13:21 zang passwd(pam_unix)[3377]: password - new password not obtained
Jan 14 14:13:21 zang PAM_smbpass[3377]: username [jck] obtained
Jan 14 14:13:21 zang PAM_smbpass[3377]: password: new password not obtained
Jan 14 14:13:23 zang PAM_smbpass[3377]: 1 authentication failure from jck for service passwd as jck(999)


--Joe





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []