[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pam-list
Subject:    passwd
From:       Al Longyear longyear () sii ! com
Date:       1996-06-22 18:03:09
[Download RAW message or body]

Michael Talbot-Wilson wrote:

> On Fri, 21 Jun 1996, Michael K. Johnson wrote:
> 
> > Red Hat Linux uses npasswd, which has lots of nice checking built into
> > it.  However, its structure really isn't built around pam...  I am
> > thinking of writing a pam-passwd package with the password checking
> > libs from npasswd and the password-changing logic from the passwd.c
> > distributed with Linux-PAM.  I would distribute it separately from
> > Linux-PAM (too huge to include, especially with the dictionaries...)
> > as pam-passwd
> > 
> > Any objections?
> 
> Well, I'd like to see a functional comparison between npasswd, passwd+ 
> and the passwd in the shadow suite.  The first two seem redundant to 
> anyone who uses shadow, at least in shadow distributions that enable 
> cracklib by default.  If the shadow passwd is not functionally inferior 
> to the others I'd be wondering why you have ignored it when it is so 
> widely used.
> 
> In other words, we are making a selection here.  Which should it be, and 
> why?  Have the alternatives been fairly looked at?

I do not quite understand the concern over this issue. It really is a
weak argument saying "we are making a selection". We are not making a
selection. We are not building applications and saying "THIS IS PAM".
PAM is a dynamic package. If you want cracklib, then write a cracklib
module which does the functions of cracklib; even just by calling
cracklib. You don't build the application to use cracklib. You build
the application to call the pam functions. How you configure the
pam.conf file is how the various tests are made and in which order.

So, a comparison of the functions is really useless in and of
itself. Even if I wrote a module which said that the password had to
be 3 characters and that was the only test does not make the module
'wrong' or 'weak'. If I included that module along with the others
then the only other condition which would be applied to the pre-built
passwd program would be that the password had to be at least three
characters.

I wrote a pam module from the passwd+ tests. I would have used npasswd
but I liked the fact that the passwd+ code used a separate set of
rules.  It is very much for the reason that I like sendmail over smail
or a lex/yacc implementation over statically defining the code in C
or pascal. It is easy to change the logic. Just add a rule.

I suppose that if I did not find passwd+, I would have used npasswd.
Perhaps if RedHat had seen passwd+ then they would have used it over
npasswd as well. However, with PAM, such a choice is meaningless.

If you like npasswd or cracklib then, by all means, write a module. I
would not say that your module was bad. As to whether or not I
personally will add your module to my pam.conf file is my
decision. The application is still the same.

-- 
Al Longyear                  longyear@sii.com             longyear@netcom.com
Finger longyear@netcom.com for a public PGP key

[prev in list] [next in list] [prev in thread] [next in thread]