Re: GSSAPI Proxy initiative

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Nov 03, 2011 at 07:47:04PM -0400, Simo Sorce wrote:
> 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.

Yes, this has been hashed over before.

You can try to pin it in memory.  And then you'd also need some way the
process could tell the kernel (e.g. when doing a system call that
required allocation) that it was working on behalf of a filesystem.  But
at that point moving context negotiation into the kernel might be more
practical.

Seems like a hard problem, but it would nice to at least have some
long-term plan.

--b.