issue with krb5_prompter_posix() design

[Nicolas Williams]

On Thu, Apr 15, 2010 at 03:23:14PM -0500, Will Fiveash wrote:
> While debugging some memory leaks relating to my pam_krb5 pkinit work I
> noticed a discrepancy between the libkrb krb5_prompter_posix() which
> requires callers to allocate the reply data buffer and standard PAM
> conversation functions which allocate the reply data buffer and expect
> the consumer of the reply data to free() it.  Here is a description from
> the Solaris Security for Developers Guide on how to write a proper PAM
> conversation function:
> http://docs.sun.com/app/docs/doc/816-4863/emrbk?a=view
> 
> Seems to me the PAM approach is better since it's acquiring the reply.

I'm not so sure.  On the one hand the conv/prompter function will know
how much memory to allocate, not the caller of the prompting function.
OTOH requiring the prompting function to free() memory allocated by the
prompter means that the application and the library must share the same
memory allocator -- a reasonable, and simplifying requirement nowadays
on _Solaris_, but not necessarily a very portable requirement.

Yeah, yeah, whoever said that PAM is intended to be portable?  Ah, but
it has turned out to be used elsewhere, outside Solaris.  But even
ignoring the fact that Solaris makes it easier/more likely for apps to
work with a single allocator process-wide (and the fact that I think
that this is a Good Thing), I believe it's best to isolate allocator use
by library.  Meaning: that an API should provide its own deallocators
for all objects that it allocates, and should not deallocate objects it
did not allocate except through their corresponding deallocators (as
opposed to free()).  This principle is difficult to apply to prompters,
I agree, but hardly impossible.

> Anyway this is adding complication to the prompter bridge function I
> wrote in pam_krb5 to allow preauth plug-ins like pkinit to prompt via a
> PAM conversation function.

It's just a SMOP :)

Nico
--