Re: trouble stacking password modules

[Joseph Konczal <joseph.konczal@xxxxxxxx>]

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



_______________________________________________

Pam-list@redhat.com
https://listman.redhat.com/mailman/listinfo/pam-list