Nicolas Williams wrote: > > On Tue, Jun 12, 2001 at 02:18:39PM -0400, Adam Slattery wrote: > > [] > > nnss_handle_t nnss_start(...); > int nnss_set_creds(nss_handle_t nnssh, nss_cred_type_t cred_type, void *creds); Maybe better is to use `const char *cred_type', to avoid another IANA cred_type_t registration? [] > 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. Note that PAM now even can't change password in all its flawors: it can't e.g. lock/unlock password (in terms of files, it is changing a passwd field). > > 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. But the change may be implemented by two modules used in different stacks for different apps runs at the same time (like classic example now with pam_unix and pam_pwdb that in fact used *different* locking mechanisms). [] > > 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). User creation may easily be handled here too. Think about solaris's switches to passwd, useradd and co -- -r files, -r nis etc. The name passed as argument will be a parameter that gets passed to pam/nnss stack, so that only module(s) that knows what's this will respond. Regards, Michael.
