[33576] in Kerberos
leaking rcache opens in gss_accept_sec_context
daemon@ATHENA.MIT.EDU (Benjamin Coddington)
Wed Jul 13 15:33:11 2011
From: Benjamin Coddington <bcodding@uvm.edu>
Date: Wed, 13 Jul 2011 15:33:05 -0400
Message-Id: <8F1FE80F-61D5-4512-A5BD-5695B3B3BBAA@uvm.edu>
To: kerberos@mit.edu
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
