On Sat, Apr 19, 1997 at 03:58:40PM -0500, Adam Slattery wrote: > 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). IMHO, PAM is good, but didn't go far enough. A new API is needed that unifies the functionality of PAM, NSS, and things like GSS and SASL. But this is academic. Noone will undertake such an API at this point. > > In short: > > - provide a modular crypt() API > > Basically done. Just needs some slight changes regardless of what I decide > to do. Can you describe the API? > > - 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. See above. I think NSS stinks and needs to be replaced with something more generic. I don't think PAM, as it is, is the right place to worry about "retrieving/storing password hashes". And by the way, I don't think it's worth worrying much about crypt password hashes. There are better password validation (initial authentication) technologies, such as SRP, Kerberos, PKI, etc... If you can use something better than password hashing, then use that. And guess what: Kerberos is the way of the future at this point -- all the major OS vendors are gravitating to it. Makes password hashing look like child's play. Consider: with Kerberos you can use one-time passwords, smartcard hardware and/or plain old passwords for initial authentication; with Kerberos you get single-sign-on and ticketing. I could go on. > 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. I really doubt that Andrew is interested in revamping the PAM API or SPI. But he can speak for himself :) > 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 think that PAM is best left as is. If you want to revolutionize this are of OS technology, design a new API and start from scratch -- seek to leverage existing code in other ways (e.g., with a PAM compatibility layer). > 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. Why can't you write a generic, modular crypt() API and let others migrate to it as they wish? If it's really so useful then it'll happen. > 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. Produce your own library and it'll be adopted, or it won't. > - Adam Slattery > http://www.sunriselinux.com/pam_crypt/ > Nico --
