Need to _kt_close() after _kt_default() ?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Need to _kt_close() after _kt_default() ?

Rick van Rein (OpenFortress)
Hi,

According to the krb5 API description for krb5_kt_default(), "The key
table is not opened."

Still, valgrind reports a memory leak in my program, and points back to
a calloc() inside krb5_kt_default().  When I call krb5_kt_close() on the
keytab this leak is gone.

Might this be a glitch in the documentation, or elsewhere?


Cheers,
 -Rick
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Need to _kt_close() after _kt_default() ?

Greg Hudson
On 09/17/2016 07:32 AM, Rick van Rein wrote:
> According to the krb5 API description for krb5_kt_default(), "The key
> table is not opened."
>
> Still, valgrind reports a memory leak in my program, and points back to
> a calloc() inside krb5_kt_default().  When I call krb5_kt_close() on the
> keytab this leak is gone.
>
> Might this be a glitch in the documentation, or elsewhere?

You definitely need to krb5_kt_close() the handle.

"The key table is not opened" is probably trying to convey that the
keytab file is not opened (for a FILE keytab), meaning that the call
will succeed if the keytab file doesn't exist.  The documentation should
be clearer.  (One could argue that a generic keytab function shouldn't
talk about the behavior of the FILE keytab type at all, but then where
in the API documentation does that go?)
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev