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. > 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. > New UNIX_and_SMB password: The next prompt is from the second pass through the password stack, so pam_smbpass is sufficiently satisfied with the current password as provided that it doesn't prompt for a different one. This password prompt comes from pam_cracklib. > Retype new UNIX_and_SMB password: > Password changed for user jck. And nothing else ever prompts for a password -- which is good, because when 'use_authtok' is set, nothing else should. > passwd: Authentication token manipulation error I'm not sure where this error comes from, but it looks very strange. Since you have pam_smbpass.so set to 'optional', the error message can only be caused by a failure in either pam_cracklib or pam_unix. Can you try to test with a simple, pam_unix only configuration; then cracklib+pam_unix; then all three? That might help narrow down the problem. > Maybe the configuration and log messages would help. > 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. > I am using very slightly modified versions of the latest releases of > both modules, but I don't think I have actually changed their behavior > yet. Where did you get the copy of pam_smbpass that you're building from? All current development on the module takes place in the Samba tree. > I am working on some patches to make this work the way I think it > should. I have been able to make the originals work right only if the > UNIX and SMB passwords are the same and the pam_smbpass module is used > before pam_unix, -- that's a sign that you're probably using an old, buggy version of pam_unix that would clear the authentication token before passing control to the next module in the stack. > [T]he modules themselves, like pam_unix and pam_smbpass, will need > to be fixed so that they actually do prompt the user for another > password if the first one doesn't work. I'm puzzled that this isn't already the case; I'm really curious to know what versions of the modules you're using, because I was fairly certain both modules did this correctly. -- Steve Langasek postmodern programmer
Attachment:
pgp00059.pgp
Description: PGP signature
