pam_cracklib: suggested changes

[David Lee <T D Lee durham ac uk>]

In trying to get the pam_cracklib module running on Solaris, I have
encountered (and solved) a few problems, and would like to propose some
upwards-compatible amendments. 

1.  One convention to assist stacking of modules is to have options
    called try_first_pass and use_first_pass.  Together with the default
    behaviour, this creates a three-way switch for getting the old and new
    passwords:
      default:         get from user, else fail
      use_first_pass:  get from modules higher on stack, else fail
      try_first_pass:  try from stack, then try from user, else fail

    I have implemented this and got it working nicely.

    Side-effect: the main loop of pam_cracklib was already getting 
    unwieldy: because this change added yet more complexity, I took the
    opportunity to tidy it up.

2.  The prompts for user-interrogation are hardcoded into the source.
    (The sys.admin. can adjust one detail.)  I propose adding new options
    to allow all three prompts to be specifiable by the sys.admin.

    (The motivation for this is trying to get pam_cracklib to interwork
    with the "poppassd" program, which itself has hard-coded lists of
    possible prompts for use via "/bin/passwd".  At present a sys.admin.
    trying to use both products is forced to adjust source code in one
    of the products.  It would seem sensible to allow flexibility.)

Comments, anyone?

In looking at those issues, I notice that several modules seem to have
much code replicated.  A related exercise (though much bigger!) would be
to try to abstract some common module functionality into a separate module
library.  (Recent discussion about syslog also relates to this.)  Again,
comments, anyone? 

It seems that, as a matter of high priority, we should think through such
commonality issues (conventions such as "try_first_pass" and possibly
propmt-specifications), and perhaps consequent library abstraction,
and head towards a consistent method of module writing.

Andrew Morgan's proposed "autoconf" work would be a good incentive for
such rationalisation.  But that seems to have dried up in recent weeks. 

Andrew, I think, wants gradual, cautious change (understandably, although
development at "pam.sourceforge.net" seems to have stopped altogether). 
On the other hand, the above suggestions (augmented by some earlier
discussion about the extent of autoconf) would indicate a more adventurous
path.  (Actually, I think we're both heading in the same direction,
towards an "Open-PAM"-like philosophy, but with different ideas about how
to conduct the journey.)

In doing the Solaris/portability/autoconf work (those three areas overlap
considerably) I am accumulating many changes, including the "pam_cracklib"
ones.  But how should I contribute these "to the greater good"? 


-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :