Expiration of RPCSEC_GSS credentials in the server

[Kevin Coffman]

Yeah, I'll look into getting the correct expiration time to send down.
 Assuming that is what we want for now?

K.C.

On 5/4/07, Frank Filz <ffilzlnx at us.ibm.com> wrote:
>
>
> 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
>
>
>
>