On Wed, May 16, 2001 at 02:17:48PM -0500, Stephen Langasek wrote: > 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. PAM_KRB5:pam_sm_authenticate() already does stuff creds into a temporary memory ccache -- all we have to do is add a call to pam_putenv()... [...] > > 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. See above. > > 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. We use a memory ccache now. > So we fall back to making sure an openafs auth module has everything it > needs for pam_setcred(). I think we can certainly add the pam_putenv() call in pam_sm_authenticate() -- we must be careful to free this env setting when pam_sm_setcred() overwrites it. And, in general, we have to be careful when using pam_putenv() to not leak memory. This (env var mem leaks) is one of the reasons I'd rather use pam data than pam env vars for inter-module communication... Normally, putenv() does not free() overridden variables for it cannot know how they were allocated and, furthermore, putenv() does not strdup() variables. I haven't looked, but I'd bet the same is true with pam_putenv(), if not in all implementations, then at least in some... *sigh* > Cheers, > Steve Langasek > postmodern programmer Cheers, Nico --
