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/
