On Wed, 10 Dec 2014 15:08:40 +0100 David Härdeman <david@xxxxxxxxxxx> wrote: > On 2014-12-10 12:52, Jeff Layton wrote: > > On Tue, 9 Dec 2014 20:55:30 +0100 > > David Härdeman <david@xxxxxxxxxxx> wrote: > >> 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). > > I'm not sure I follow completely...first of all, rpc.gssd is also not > namespace-aware, is it? I mean, sure, it could be run in a given > namespace, but there can still only be one rpc.gssd running? > gssd isn't namespace aware, but it doesn't have to be since it gets started in userland. In principle you could run a gssd per container[1]. As long as each container has its own net namespace, each gssd would have its own set of rpc_pipefs pipes. request-key is different. The kernel spawns a thread that execs the program, but there's no support in that infrastructure for doing so within a particular container. > Also...the nfsidmap binary (the request-key helper) isn't > namespace-aware...is it? > No it's not. I'd consider that a bug as well. [1]: "container" is an overloaded term. In this discussion, I'm using it as a generic name for a set of namespaces. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
