I think that leaving password changing modularity to PAM is probably
best and will save you trouble. But you may have to export a modular
crypt() interface to password changing modules, in which case you might
as well export such an interface to authentication modules, pam_unix in
particular.
What I'm saying is: a modular crypt() API would be nice, and it would be
nice if pam_unix used it. It would also be nice to have PAM modules
whose purpose is merely or primarily to provide password changing
functionality for use with a particular name service (e.g., pam_nis,
pam_nis+, pam_ldap, etc...).
In short:
- provide a modular crypt() API
- let pam_unix provide an authentication module for use with
getpwnam()/getspnam() and crypt().
- let pam_etcshadow, pam_nis, pam_nis+, pam_ldap, etc, provide crypt()
password changing for those name services
Of course, some name-service specific modules, e.g. pam_ldap, may
provide authentication support as well since there may be a way other
than the traditional getpwnam()/getspnam()/crypt() approach to
authenticating users with such name services.
IMHO,
Nico
On Thu, Apr 19, 2001 at 12:30:41AM -0400, Adam Slattery wrote:
[...]
> 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
>
>
>
>
> _______________________________________________
>
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
--
