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. :
