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

Re: trouble stacking password modules



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: pgp00002.pgp
Description: PGP signature


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