leaking rcache opens in gss_accept_sec_context

[Benjamin Coddington]

On Jul 14, 2011, at 9:40 AM, Greg Hudson wrote:
> On Wed, 2011-07-13 at 15:33 -0400, Benjamin Coddington wrote:
>> Anyway, calling gss_accept_sec_context this way allows svcgssd to
>> create a context for any requested service name -- but the problem we
>> found is that svcgssd opens the kerberos replay cache for every
>> context/cred created, eventually reaching ulimit.  The files are never
>> closed, and every so often the rcache is removed and re-written, so
>> the handles themselves are to deleted files.
> 
> The files should be closed in gss_delete_sec_context() (via
> gssint_delete_internal_sec_context -> krb5_gss_delete_sec_context ->
> krb5_auth_con_free -> krb5_rc_close).  Is it possible that svcgssd is
> leaking the security contexts?
> 
> There is a behavior difference here depending on how the server invokes
> gss_accept_sec_context().  If the server imports a name and acquires
> credentials, the rcache handle is associated with the credential object.
> If the server uses the default credentials or name, the rcache handle is
> associated with the security context.  If svcgssd leaks security
> contexts but not credentials, you would only see the rcache leak when -n
> is used.

It shouldn't leak -- it roughly loops on

gss_acquire_cred
gss_accept_sec_context
gss_export_lucid_sec_context
gss_delete_sec_context

I found that before we got to gss_delete_sec_context(), we had already tried to clean up the context in gss_krb5_export_lucid_sec_context() -> krb5_gss_delete_sec_context(), which fails with G_VALIDATE_FAILED.  It also sets the context to GSS_C_NO_CONTEXT, so once we get to gss_delete_sec_context(), context validation fails there too.

I found your message to K.C. in May (http://marc.info/?t=130470507900001&r=1&w=2).  Do you have a patch we could try?

Ben