Ok, a few things first. (This is a pretty long email, sorry :)
For various reasons, pam_crypt is no longer at whstechs.org and that will
never be the "primary" distribution site again. Unfortunately email died
as well some time today. The last message I got was from Steve Langasek at
4/17/01 6:36 pm (CST). I'll check the archives but not all of the emails
seem to appear there so if you could resend anything to my new address
I'd appreciate it.
The new site will be www.sunriselinux.com/pam_crypt. If that doesn't work
for you yet (because of dns), seculinux.hackersclub.com is the same site.
My new email address is aslattery@sunriselinux.com.
This is hosted on a faster and much more reliable connection. It will
probably be the main distribution site for some time (if not forever). I
think there may be some down time next week when they switch ISPs. I was
planning on moving to sunriselinux.com after the switch, but was forced to
make the move prematurely because of whstechs.org problems.
I got rid of getpass(). I can't believe I used it in the beginning. That
was stupid. Anyway, pam_crypt gets user passwords correctly now. I
released a new version for this fix because of the upcoming changes
described below. You can get it off the main distribution site. It's
version 0.0.4.
Based on the recent discussion on the list, I've decided to make a pretty
major change to pam_crypt. A lot of people have been talking about
nis/nis+/berkeleydb/ldap/nss. I've had a few thoughts on the best way to
do this, but Nicolas Williams really got me thinking with his mention of
modular password changing. Why implement that stuff statically? The main
goal of pam_crypt is to be versatile and (as you guys have shown me)
versatility is severely limited without support for differant methods of
getting authentication information (password hashes).
So what I'm going to do is create an API similar to the hashing algorithm
modules interface for obtaining and updating hashed authentication tokens.
This could be a little more tricky, but i'm sure it can be done. I'd like
to hear some ideas on the best method of accomplishing this task. Right
now I really only have 1 idea that I like:
In the config file have a section like (similar to salt list):
DEFAULT_TOKEN nss
"x" nss
"+NIS" nisplus
"NIS" nis
"" bdb
"" ldap
Then with this the default_token would be the module used to get the
preliminary password (/etc/passwd) and this token would then be
compared with the stuff in quotes (ie "NIS") and if a match was
found that module would be called to get the shadow entry. Otherwise
the default_token would just be used again. For those entries with null
tokens ("" bdb) they would never be called unless you used them as the
default_token or specified them as the default_token in the pam.d file.
I am open to suggestions about better ways of doing this. In fact, I'd
love to hear some alternatives (but I do like my current idea).
After this code is working I'll make a module that uses nss. I don't have
the resources to test some of the modules that a lot of people would
probably like to see. For this reason I have been considering three ways
of distributing the less commonly used modules:
1) Make a page of modules with descriptions. (like PAM does on kernel.org)
2) Make a seperate tarball with all of the modules
3) Include them in the main release
Each has their costs and benefits. I don't really like option #3 because
some of the modules that get written might be rather obscure. I'm
currently leaning towards option #1 for licensing issues.
Solar Designer said there was a possibility for corrupting the password
file. I think this is with the call to rename(2) but if anybody knows what
he was refering too i'd like to be enlightened :). I'm not 100% happy with
my current code for updating the password file. I'm going to do it
correctly this time (with the nss module).
I might also be changing the api for the algorithm modules. I did a few
things because I had some Ideas I was considering, but I decided against
most of them or I decided they are rather pointless (like the function to
get random data. I'm not sure if I should keep this or not). This isn't
a big deal really, I just thought I'd mention it.
-Adam Slattery
