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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos