issue with krb5_prompter_posix() design
will.fiveash at oracle.com
Thu Apr 15 18:26:09 EDT 2010
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
Note my new work e-mail address: will.fiveash at oracle.com
Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/
More information about the krbdev