leaking rcache opens in gss_accept_sec_context

[Greg Hudson]

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.