Re: Why should setcred be called after session open?

[Nicolas Williams <Nicolas Williams ubsw com>]

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
--