[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130523201431.GB13640@fieldses.org>
Date: Thu, 23 May 2013 16:14:31 -0400
From: "J. Bruce Fields" <bfields@...ldses.org>
To: Jeff Layton <jlayton@...hat.com>
Cc: Boaz Harrosh <bharrosh@...asas.com>,
Stanislav Kinsbursky <skinsbursky@...allels.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
viro@...iv.linux.org.uk, serge.hallyn@...onical.com,
lucas.demarchi@...fusion.mobi, rusty@...tcorp.com.au,
linux-kernel@...r.kernel.org, oleg@...hat.com,
linux-fsdevel@...r.kernel.org, akpm@...ux-foundation.org,
devel@...nvz.org
Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced
On Thu, May 23, 2013 at 03:55:47PM -0400, J. Bruce Fields wrote:
> On Thu, May 23, 2013 at 09:05:26AM -0400, Jeff Layton wrote:
> > What might help most here is to lay out a particular scenario for how
> > you envision setting up knfsd in a container so we can ensure that it's
> > addressed properly by whatever solution you settle on.
BTW the problem I have here is that the only case I've personally had
any interest in is using network and file namespaces to isolate nfsd's
to make them safe to migrate across nodes of a cluster.
So while the idea of making user namespaces and unprivileged knfsd and
the rest work is really interesting and I'm happy to think about it, I'm
not sure how feasible or useful it is.
I'd therefore actually prefer just to take something like Stanislav's
patch now and put off the problem of how to make it work correctly with
user namespaces until we actually turn that on. His patch fixes a real
bug that we have now, while user-namespaced-nfsd still sounds a bit
pie-in-the-sky to me.
But maybe I don't understand why Eric thinks nfsd in usernamespaces is
imminent. Or maybe I'm missing some security problem that Stanislav's
patch would introduce now without allowing nfsd to run in a user
namespace.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists