On Tue, 15 May 2001, Nicolas Williams wrote: > > Yep.:) It's the cleanest way -- this way, once we have the credentials, we > > always have a KRB5CCNAME that points to them. > *mumble* > Ok, we'll think about implementing that at some point. Currently only > setcred() does it, and with the final ccache, not the memory-based > ccache used in between authenticate() and setcred(). I'd be happy to do it now, but as I said, my understanding of memory-based ccaches isn't particularly solid, including my understanding of the APIs used to accomplish this. > > Use of the KRB5CCNAME env var is a standard mechanism for communicating > > Kerberos ccache information. It is, however, inappropriate for PAM modules to > > modify the calling application's environment in this manner. Imagine the > > chaos that would ensue if you had an asynchronous authentication server > > processing 10 Kerberos logons at the same time! So a PAM module that needs to > > use environmental variables should be able to find them in the application's > > environment, but should give precedence to local PAM env vars if present. > I didn't mean calling putenv() directly! What made you think I did? :) Just pointing out the problems with using the native Kerberos mechanism directly, in case anyone else were to suggest it. :) Since we can't call putenv() ourselves, we can do the next best thing. > > At which point we're even worse off, because you then have a non-standard > > interface used to pass data between these two particular PAM modules. > > pam_get_data() really ought only be used for data specific to a single module. > > For passing Kerberos ccache information, $KRB5CCNAME is the standard > > mechanism. We're simply mirroring this by making it available as a PAM env > > variable instead of an application env variable. > Well, I think PAM modules will find themselves communicating one way or > another with each other. Since AFS uses Kerberos it does make sense for > there to be a convention by which PAM_KRB5 and PAM_AFS communicate -- > wether they use PAM data or PAM env vars is not terribly important, I > suppose. Except I see a significant difference here between using a pam env var which mirrors a standard interface, and using pam_set_data() to establish a private 'token' whose meaning is detached from the rest of the system. > > We need to be doing pam_putenv(KRB5CCNAME) regardless of pam_openafs, as this > > is the mechanism PAM defines for exposing env vars to the application. > The question is wether to do that with the temporary memory ccache in > pam_krb5:pam_sm_authenticate(). Till now only pam_krb5:pam_sm_setcred() > did pam_putenv(KRB5CCNAME). Yep. I think the temporary memory ccache would be ideal. I also know I'm personally not going to be able to implement it in the near future -- not until I read up on the subject. > Not that it matters that much -- the MIT krb5 memory ccache uses SysV > shared memory, which means the ccache is left lying around in the system > if it's not explicitly deleted (ugh!). I'd rather there were an > optionally anonymous mmap() memory ccache that could be guaranteed to go > away when the last process to have it mapped exits. Ah. Yes, that's not pretty. :P Then we would have to guarantee that every call to pam_authenticate() is followed by pam_setcred(ESTABLISH) and pam_setcred(DELETE), even if pam_authenticate() fails. :/ So ideally, we could use a memory ccache, but in practice, the available Kerberos implementations pose some problems for us if we do. So we fall back to making sure an openafs auth module has everything it needs for pam_setcred(). Cheers, Steve Langasek postmodern programmer
