[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_crypt design changes



Andrew, I know this message is long, but I would really like you to read it.

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

This actually sounds like a pretty good idea.

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

"Why reinvent the wheel."  I see your point, there are already modules to
handle a lot of things and implementing the idea I described in my last post
would really make most of the other authentication modules completely
obsolete. Maybe this wouldn't be bad, but at the moment pam_crypt isn't much
better than anything else aside from it's bcrypt support and support for
arbitrary password file location based on service (which I haven't really
tested much).

> In short:
>  - provide a modular crypt() API

Basically done.  Just needs some slight changes regardless of what I decide
to do.

>  - let pam_unix provide an authentication module for use with
>    getpwnam()/getspnam() and crypt().

This saves me from coding an interface to use nss (which would definately
need to be done otherwise).

>  - let pam_etcshadow, pam_nis, pam_nis+, pam_ldap, etc, provide crypt()
>    password changing for those name services

It depends on how you think retrieving/storing password hashes "should" be
handled.  With my original idea, you would have one main module that would
totally replace pam_unix along with a few other authentication modules.  It
would also pretty much completely take over the main responsibilities for
the auth and password fields in pam.d files.

On the other hand, you would change either the api for the pam modules (by
adding a function to libpam.so) or you would have to patch every
authentication module.  With this though, there would be no need to
reimplement/copy modules such as pam_unix.

Both ways have their advantages and disadvantages, and both will
revolutionize PAM. The differance is one does it at the user level and one
does it at the (module) programmer level.

How revolutionary and rebelious are you, Andrew? :)

I really don't know which would be best, but to move forward I'm going to
have to pick one to focus on.  A large part of my decision depends on what
Andrew thinks.  If he doesn't want to add a crypt() interface to PAM-Linux
for modules to call, I will be forced to go with my original plan.  This is
probably the reason I never really considered anything like Nico's idea.


There is yet another option, and that is to do this in glibc.  I've ruled
that out already.  It's basically impossible to get major changes in glibc
unless you are part of the "in-crowd."  And glibc is insanely messy.  Go
look at the makefile layout if you don't believe me.

- Adam Slattery
http://www.sunriselinux.com/pam_crypt/





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []