> > This thread could get very messy... :) > > Indeed. My prediction has come true. > > Yes, I have thought about something like this, but not as a pam module. As > > a pam module it would be impossible because pam has no interface for > > applications to get information such as the home directory or the shell or > > even simple things like the uid/gid. PAM simply doesn't do this. > > I think one way to start might be to add a user-profile-attribute-get > function that takes an optional PAM handle (optional because > authenticating to the name service may not be necessary). This would actually be a wonderful solution, but it would further rip Linux-PAM away from other PAM implementations and I'm not sure how Andrew would like this. I asked about this a few months ago during one of the pam_crypt threads but never got anybody's opinion. If this was added, I would recommend it use a fifth (new) module type. If this is in fact a viable option that we (pam-list :) would like to pursue, we could then discuss what functions would be required of this module type. This is the SPI you talk about below. So let's go with the idea of some additions to the PAM API. This would be much simpler, could be implemented much faster, would be more widely accepted and used, could provide an equivalent end-result, and relies on a stable and proven API (PAM). > > What is needed is something above pam and even nss to handle "all" aspects > > of user authentication as well as a modular interface to replace nss. Such > > an API would need to have something similar to getpwnam(), but it would > > also need something like putpwnam(). Actually, the more I think about this, it seems like this could be done in PAM. > Don't get so ambitious. Name services should be mostly read-only. There > are too many different backend possibilities to be able to write a > generic write API for name services(*). There's no puthostent(), and not > just because DNS updates haven't been available till recently. > > There's a lot to think about, and I would rather there were no standard > write-side API for name services. I'm a sysadmin -- I know how difficult > name space management can be -- most shops build tools and scripts to > match their problems and goals. Solutions are needed, but I think they > should be product-specific, not standard, otherwise I'm afraid we'd get > stuck with a bad standard. Ever look at XFN? I think you are wrong here. There should be a generic write API. Of course, it must be modular. I'm not sure if you were taking that fact into consideration. Name space management can be difficult, and I strongly feel that a read-write API would simplify it more than a read-only API. IMHO, having the ability to both retrieve and set (read-write) user attributes (shell, home directory, uid, gid, etc) would provide much greater flexibility than a read-only API. > > int pam_get_user_attr(pam_handle_t pamh, char * user, char * attr, void **val); > > maybe. Type information might be a nice addition: > > int pam_get_user_attr(pam_handle_t pamh, char * user, char * attr, enum > pam_user_attr_types type, void **val); > > maybe. Multiple values would be nice as well. Well, I think the second prototype would fit into PAM better (going mainly by pam_get_item()). This way, the application can request the attribute it needs directly. Multiple values probably aren't required, but I'm not sure. > > And so on. But then, you also gotta think about the SPI (i.e., the > interfaces exported by the modules to implement this), including > stackability considerations (i.e., what's it mean to have multiple > modules that know different values of a given attribute for the same > user. And then you need a standard set of attributes to replace > getpwnam() with, a standard set of attrs to extend getpwnam() with, > etc... Stackability isn't really an issue. If differant "required" modules have differant information, return failure. Certainly it would take some planning on the administrator's part to set this up correctly if he/she wanted to stack this type of module, but it really wouldn't be a problem. Yes, we would need to decide on a standard set of attributes. Everything getpwnam() provides should be sufficient; I can't think of anything else that would be needed by the application, but additional attributes could be transparently added if we used the second prototype above. Now, here is another hypothetical problem that is identical to the problem I was facing with pam_crypt. How do authentication modules obtain these attributes? The main attributes that authentication modules would need are the hashed token (password) and account expiration information. Coincidentally, these are the things in /etc/shadow. The authentication modules would rely on PAM to obtain these attributes. We can probably do this (for the module) in one of two ways. Either add a pam_get_item() feature, or create a new call solely for dealing with these authentication attributes. It would probably be much simpler and much better to add things to pam_get_item(). Another issue that would arrise is the fact that in order to authenticate a user, not only must the authentication stack succeed, but the "user attribute" stack must also succeed if the authentication stack needs information from the "user attribute" stack. > > Very non-trivial. Of course, I never said this would be simple :). But this would be cool and would increase the flexibility of PAM dramatically because it would no longer rely on nss, just like it doesn't rely on crypt(3) (pam_unix, pam_pwdb, ...pam_crypt :) This certainly seems like it could be a wonderful addition to the PAM API. It would certainly take some work, but it could be done. > > - Adam Slattery > > aslattery@sunriselinux.com > > Nico - Adam Slattery
