issue with krb5_prompter_posix() design

[Will Fiveash]

On Thu, Apr 15, 2010 at 04:03:17PM -0500, Nicolas Williams wrote:
> 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.

Yeah, I think it's more accurate to say PAM got it half right in that
PAM conversation/prompter functions allocates the reply buffer but,
yeah, it should provide a deallocation function also.

Now back I go to memory leak hunting (thank you libumem for making this
easier).
-- 
Will Fiveash
Oracle
Note my new work e-mail address: will.fiveash at oracle.com
http://opensolaris.org/os/project/kerberos/
Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/