Re: [PATCH 00/19] gssd improvements

[Jeff Layton <jeff.layton@primarydata.com>]

On Tue, 9 Dec 2014 20:55:30 +0100
David Härdeman <david@hardeman.nu> wrote:

> On Tue, Dec 09, 2014 at 09:58:13AM -0500, Jeff Layton wrote:
> >> On 2014-12-09 14:09, Jeff Layton wrote:
> >>> One thing that _would_ be nice while you're in here though would be to
> >>> help parallelize more of process_krb5_upcall. Currently it forks before
> >>> changing its identity and then the parent waits on that to exit which
> >>> keeps everything serialized.
> >
> >Ahh, now I remember. It's not the closing of the fds that's the
> >problem, but you do need to have some way to reap the exit status from
> >the processes that are being forked off (so you don't end up with
> >zombies).
> 
> That's probably something that's been looked into before with libevent
> (says he, without doing any research).
> 

I imagine so.

> Another question that comes to mind...if we're anyway forking a child
> per gssd request...how far has the idea of changing rpc.gssd over to a
> /sbin/request-key helper been considered? I've seen some traces of
> historical discussions via google but nothing concrete so far...
> 

(cc'ing David in case I'm wrong on this point)

Yes. The problem with keyrings is that while the in-kernel parts are
namespace-aware, the upcalls are not. /sbin/request-key is spawned by a
kernel thread that lives in the init namespaces. Any solution that
involves a usermodehelper upcall will need to figure out how to handle
containerized clients.

Another idea might be to scrap rpc.gssd altogether and communicate with
gssproxy directly (but that too involves running a daemon, of course).

-- 
Jeff Layton <jlayton@primarydata.com>