Thoughts on initial ticket acquisition/verification on Sun (slightly OT)

Henry B. Hotz hotz at
Thu Nov 17 03:48:29 EST 2005

I'm sure Sun can whip up one that suits them better, but since  
there's interest I'll see if I can get it released.  I need to figure  
out that process anyway.

On Nov 17, 2005, at 12:06 AM, Frank Cusack wrote:

> On November 16, 2005 5:12:01 PM -0800 "Henry B. Hotz"  
> <hotz at> wrote:
>> I just finished an auth plugin for Sun LDAP 5.2 that will accept  
>> a  simple bind username/password
>> and verify it against a K5 server.
> ...
> Nice.  Will you be making the code available?  I'd very much like  
> to see it.
>> Nico suggested that I consider using PAM for this function.
> Deficiencies in Sun's or other pam_krb5's aside, most applications  
> leak
> memory on PAM authentications.  The responses (the 'resp' argument to
> the pam conversation function) are generally leaked.  For fork/exec
> applications, the authentication happens in the forked child so this
> usually goes unnoticed.

Would that include the privsep option for OpenSSH?

> It seems unlikely to me that Sun LDAP 5.2 uses a fork/exec model,  
> so you
> should verify that the Sun LDAP 5.2 server does not leak these before
> going the PAM route.  Running the LDAP server with libumem might be  
> able
> to show leaks.
> -frank

Threading, not forking.  Would make a leak more relevant, not less, I  

Module intended to be thread safe, but hasn't been stressed enough to  
show issues there yet.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at, or hbhotz at

More information about the krbdev mailing list