Re: leaking rcache opens in gss_accept_sec_context
On Jul 20, 2011, at 1:07 AM, Greg Hudson wrote: On Tue, 2011-07-19 at 16:21 -0400, Benjamin Coddington wrote: >> 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. > > Aha. Yes, that's the bug you found a reference to. (And thank you for > explaining why that bug wasn't resulting in gssd crashes for everyone in > previous releases. I had forgotten about the pointer validation code.) > I've attached the patch which is due for krb5 1.9.2. > > gss_delete_sec_context should be unnecessary when > gss_export_lucid_sec_context succeeds. Of course, it's harmless given > the way GSS handles contexts (nulling out the pointer when they are > released). > > Thank you, Greg. I can confirm that this fixes the problem we were seeing. It also fixes a leak when running without '-n', which was less obvious because we didn't open a new handle to the rcache each time. Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: leaking rcache opens in gss_accept_sec_context
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=13047050791&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
leaking rcache opens in gss_accept_sec_context
I am working on a linux NFS cluster that requires a single svcgssd to establish contexts under multiple service names. In this scenario, svcgssd can be started with "-n" so that it acquires creds at context creation. The behavior with "-n" is to call gss_accept_sec_context() with a NULL verifier_cred_handle instead of a gss_cred that was created beforehand with gss_acquire_cred(). I believe that the NULL verifier_cred_handle causes the kerberos code to try to create creds - perhaps by trying to create a cred for each principal in the keytab.. I am not an expert in the kerberos code. 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. Is it advisable to call gss_accept_sec_context with a NULL verifier_cred_handle, and if so -- what can we do to release resources/close rcache each time? Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
