On Tue, 12 Jun 2001, Nicolas Williams wrote: > On Tue, Jun 12, 2001 at 02:18:39PM -0400, Adam Slattery wrote: > > > > I speak of traditional old-school authentication (pam_unix). > > Things like kerberos have differant needs, but we must keep /etc/passwd > > style authentication in mind. This is why I am pushing for a read-write > > API. > > I suppose I would be willing to settle for this: > > - a user profile attribute/value based API for reading > - a user profile attribute/value based API for writing > - a statement that the ability to change user profile attributes will > depend on the modules in the stack, and that coders should not expect > writes to work in all circumstances Ok. This sounds good. Conflict resolved. > Now, I'd like to follow a comment I made just before, that this API > should not be a part of PAM after all, but external to it, with a > function for apps to pass in the credentials they have available, > including PAM handles. This was one of my original concerns; I wasn't sure if it would be a good idea to add this to the PAM API. Perhaps this could be distributed with Linux-PAM as a seperate library? (see below). Then other questions arrise: Where do you store modules? config files? I suppose /lib/security/ and maybe /etc/nnss/ (like /etc/pam.d/) would work. > Let me use 'nss_' as a prefix, or perhaps, 'nnss_' (new nss). > > nnss_handle_t nnss_start(...); > int nnss_set_creds(nss_handle_t nnssh, nss_cred_type_t cred_type, void *creds); > > int nnss_get_user_prof_attr(nss_handle_t nnssh, /* optional */ > char *nnss_service, /* optional -- use > * configured stack if > * not specified */ > char *user, > nnss_attr_type_t type, > char *attr, > void **val /* another function should > * handle multi-value attributes? */ > ); > > and so on, including a similar set attr function. > > Cred types would include: GSS-API creds, Kerberos creds, PAM handles, > etc... ok, sounds good. > Attribute types would include int(8, 16, 32, 64), uid_t/gid_t, string > (char *), and so on. uhuh. > Calls to nnss_get_user_prof_attr could be made with a null nnss handle, > meaning "use whatever creds you can find in my environment, if you need > any." > > Then only one thing need be added to PAM: a new PAM item to store an > nnss handle. I think everybody would be happier about that. If we do a library like this, I definately think it should eventually be distributed with Linux-PAM since a goal will probably be to have most modules and PAM-enabled applications use this API once it is completed (which may take some time). > > > > On Tue, 12 Jun 2001, Nicolas Williams wrote: > > > The biggest problem is this: whereas a read-only API can be generic > > > enough to apply different name services and data models with rather > > > little pain, the same is NOT true of write APIs. > > > > Like I have said in other emails, some PAM modules "require" the ability > > to write certain user attributes. I'll relate this to what is probably > > the most widely used module: pam_unix. Pam_unix needs to be able to write > > a hashed password to wherever user-attributes are stored (traditionally > > /etc/passwd). It is an apsolute neccesity. As of now, "/etc/passwd" > > and "/etc/shadow" are hard-coded into the functions used to store this > > information in pam_unix. This is bad if you want to use some alternative > > place (or method, like a database) to store authentication information. > > Clearly, changing passwords is exceptional. And that's the only user > item that PAM can change. You can't use PAM, as it is, to change a > user's shell, and I now believe PAM should not be extended so you > could. Ok. Right now I am still leaning towards a relatively broad write-side API that could at least attempt to change other attributes (such as the shell), for reasons such as the file locking issue (discussed below). Reliability would be no differant really; if the administrator was using a module to store and retrieve attributes from /etc/passwd and friends, it would be just as reliable as a putpwent scheme, but it would have several added benefits (the biggest being file locking schemes). > > Another issue is that pam_unix currently handles the rewrite of > > /etc/passwd. This should not be handled by the password module. If there > > are two differant password modules being used by differant services and > > they both need to update these files at the same time, they "must" use the > > same locking scheme. This may be an unlikely scenario, but it is a real > > concern for administrators who might wish to use differant password > > modules in differant services that both rely on the same file. > > Hey, the modules get called in order, so there's no locking issues > there. Wrong. I said "differant services." With differant services, differant modules might be executed simultaneously, thus creating the possibility for file corruption if they use differant locking schemes. > > > Also, I only want to integrate a getpwnam() replacement > > > API with PAM, not necessarily all of NSS. > > > > Yeah.. of course. We are only dealing with user authentication, not ethers > > or protocols. All I would want to implement is a replacement that can > > handle everything that might be done with the passwd, shadow, and group > > entries in nsswitch.conf. > > I was thinking of gethostby*() and friends, which are also part of NSS, > and which I don't want to mess with now (though they too need > extensibility). Well in the very distant future perhaps "nnss" could be extended to include other parts of nss in the same way it handles user attributes, but I'm really not concerned with this. > > One of your main reasons for wanting to replace nss is the lack of > > flexibility from getpwnam(). One of my main reasons is the non-existance > > of putpwnam(). > > Ok. I can see that, but, as I said, you can't expect a write API to work > with all name services -- you care about the 'files' name service, and > so a simple API will probably do for you (but even here, I don't care to > cover user creation, and if you have no transactional interface, then it > may be an inefficient interface). Ok. We are in agreement at least. The write API should exist, but the application/module must be very aware of the possibility that the write attempt will fail. As far as user creation is concerned, it is not something that is needed at this time, but with a flexible API at least the possibility would be open in the future. User creation would be terribly inefficient with no transaction interface, but this could probably be added if there was a demand for it. Let's not worry about this for now; I know you don't care or have a need for this, and I'll tell you now that I don't either :). > > In a previous e-mail you said there was no putpwnam(). Well, there > > "should" be a putpwnam(). If we are going to replace getpwnam(), we > > should create something along the lines of putpwnam(). Just because it > > hasn't existed in the past doesn't mean it shouldn't exist in the future. > > I still disagree, but I think that some user attributes are easy enough > to handle that we can probably deal with them in a read-write API. Which is all that is needed as far as PAM is concerned. > Both of the prototypes I suggested were of the one-attr-at-a-time type. hmm. That wasn't the impression I got, but ok :). Looking at them a second time, you are correct. > > - Adam Slattery > > Nico - Adam Slattery
