Expiration of RPCSEC_GSS credentials in the server

[Frank Filz]

In debugging the problem with the rpcsec_gss_krb5 module reference
count, I noticed that rpc.svcgssd sets an "end of time" expiration when
it passes security contexts into the kernel, as shown here:

static int
do_svc_downcall(gss_buffer_desc *out_handle, struct svc_cred *cred,
		gss_OID mech, gss_buffer_desc *context_token)
{
	FILE *f;
	int i;
	char *fname = NULL;
	int err;

	printerr(1, "doing downcall\n");
	if ((fname = mech2file(mech)) == NULL)
		goto out_err;
	f = fopen(SVCGSSD_CONTEXT_CHANNEL, "w");
	if (f == NULL) {
		printerr(0, "WARNING: unable to open downcall channel "
			     "%s: %s\n",
			     SVCGSSD_CONTEXT_CHANNEL, strerror(errno));
		goto out_err;
	}
	qword_printhex(f, out_handle->value, out_handle->length);
	/* XXX are types OK for the rest of this? */
	qword_printint(f, 0x7fffffff); /*XXX need a better timeout */
	qword_printint(f, cred->cr_uid);
	qword_printint(f, cred->cr_gid);
	qword_printint(f, cred->cr_ngroups);
	for (i=0; i < cred->cr_ngroups; i++)
		qword_printint(f, cred->cr_groups[i]);
	qword_print(f, fname);
	qword_printhex(f, context_token->value, context_token->length);
	err = qword_eol(f);
	fclose(f);
	return err;
out_err:
	printerr(0, "WARNING: downcall failed\n");
	return -1;
}

This means that when cache_clean() is walking the server security
context cache, it will never expire these credentials.

For debugging, I tried a timeout of 10 seconds:

	qword_printint(f, time(0) + 10); /*XXX need a better timeout */

That at least proved that with an expiration timeout, and fixing the
context refcount bug, the contexts do get cleaned up. I was also able to
verify that the server does act correctly when they have expired and a
new client request comes in.

Bruce suggested using the ticket expiry time:

> Yeah, it's a good question.  The ticket expiry time would be the
> obvious
> thing.  That can still be pretty long, and I do worry about how big the
> cache could grow, so it would be nice to have some more logic to prune
> the cache when it gets too big, keep track of when contexts were last
> used, etc.  That'd be more involved, but it'd be a great next project if
> you're looking for something....

It would definitely be good to have some kind of cache management like
this. An LRU list and dropping contexts when the cache gets too big
would be one option. Another would be to renew the expiration for some
modest amount of time each time it is used (but never renew it past the
ticket expiration time).

I was also thinking it would be nice if there was some kind of signal so
the kernel cache could be completely cleaned up if the rpc.svcgssd
process exited. That would allow a clean shutdown procedure (stop
rpc.svcgssd, then remove the rpcsec modules if desired) no matter what
the expiration times were.

Frank Filz