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

[Henry B. Hotz]

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 jpl.nasa.gov> 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  
think.

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 jpl.nasa.gov, or hbhotz at oxy.edu