GSSAPI Proxy initiative

[Simo Sorce]

On Thu, 2011-11-03 at 15:16 -0700, Myklebust, Trond wrote:

[..]

> No, but we still need to be able to do recovery of rpcsec_gss contexts
> once they are broken, and right now we have a major flaw due to the
> fact that recovery depends on a lot of small processes and data that
> is allowed to be swapped out at the moment when we need them the most
> (i.e. in a memory reclaim situation).
> 
> If the server reboots while our client is in the middle of writing
> back a file (or several files), then the client needs to recover those
> rpcsec_gss contexts that authenticate the processes which own any
> dirty pages that remain to be written out.
> Key security is an irrelevant concern once your kernel deadlocks in an
> OOM state.

[..]

> > Currently credential caches are stored in files, is there a problem
> > with that model ? Do you need access to credential caches from the
> > kernel when under memory pressure ?

> Yes, there is a major problem with that model, and yes we do
> potentially need access to credential caches when in a recovery
> situation (which is a situation when we are usually under memory
> pressure).

This sounds like a catch 22 situation.
Even if the keys are pinned in kernel memory you still need the GSSAPI
Proxy daemon in order to re-establish the security context, and that
process could have been swapped off too.

I am not sure I see a way out here.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York