On Wed, Jun 13, 2001 at 02:53:24AM +0400, Michael Tokarev wrote: > Nicolas Williams 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, I was just throwing around some suggestions. Yes, 'const' must be used where it makes sense. And no, there's no IANA for PAM items, why would there be one for nnss? > > 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). ?? PAM does no locking. PAM modules do lock/unlock resources as needed, depending on the module, of course. ... > > 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). It's the modules' responsibility to get locking right, not the PAM framework's, and that's just fine. I would expect the same for nnss. > [] > > > 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. PAM has no API for the app to specify a PAM config -- the -r argument to /bin/passwd on Solaris is not implemented via PAM. Of course, you can always make PAM services called 'files', 'nis', 'nis+', etc.. so the -r argument to passwd can be implemented trivially: by making the PAM service its argument. > Regards, > Michael. Cheers, Nico --
