On Mon, Jun 11, 2001 at 04:37:19PM -0400, Adam Slattery wrote: > Good afternoon, > > This thread could get very messy... :) Indeed. > 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). > 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(). 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. (*) Think: - how would you model the name service objects? - as objects with references to each other? - as textual objects with soft references to each other? - what about groups and their members? - what about schemas? - how do you make them (schemas) extensible? - how about run-time schema extensibility? - what about referential integrity? - transactions? - etc.... 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? > Nicolas: since you have talked about this before, have you ever thought > about (or actually started...) designing a new api? See above. 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. 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... Very non-trivial. > > - Adam Slattery > aslattery@sunriselinux.com > Cheers, Nico --
