On Wed, Jun 13, 2001 at 12:57:15AM -0400, Adam Slattery wrote: > > > On Tue, 12 Jun 2001, Nicolas Williams wrote: > > > On Tue, Jun 12, 2001 at 02:18:39PM -0400, Adam Slattery wrote: > > > 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). Or totally separately from Linux-PAM. The only change to PAM that would be needed would be a new PAM item for passing an nnss handle to PAM. > Then other questions arrise: Where do you store modules? config files? To be figured out. I think some stackability of modules would be nice. > > 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). I would not expect nnss to do any locking itself, locking belongs in the modules (as with PAM). > > 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. Within a PAM handle instance, modules get called in order. It's upto the modules to perform locking, if need be, to synchronize with other running instances of PAM handles. That's how it is *now* with PAM, and it's just fine that way. > - Adam Slattery Cheers, Nico --
