Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

[ebiederm@xmission.com (Eric W. Biederman)]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Wed, May 22, 2013 at 11:35:56AM -0700, Eric W. Biederman wrote:
>> ebiederm@xmission.com (Eric W. Biederman) writes:
>> 
>> > I am missing a lot of context here and capturing the context of a
>> > process at time time we mount the filesystem and reconstituing it in
>> > call user mode helper seems like something we could do.
>
> So it's not enough just to ensure that the user namespace is set
> correctly?  (To the namespace of the mount process in the nfs case, or
> of the process that starts nfsd in the nfsd case.)

No.  By just setting the user namespace, you gain the ability to create
processes outside of your curremt rlimits, and cgroups, and pid
namespace, etc.

With the wrong set of namespaces you will talk to the wrong processes,
or utilize the wrong resources.

Outside of your current cgroup you gain the ability to use more
resources than you were limited to.

Having thought about it what I would propose is to fork a process from
the context of the mounting process (or possibly from the context of the
process that writes to the sysctl that sets the program to spawn) and
have that process be a daemon that becomes responsible for spawning user
mode helpers with context.  Either that or whe need the user mode helper
userspace infrastructure to become namespace aware and call setns.

>> If we want to do something like this the only sane thing I can see is to
>> have a per container version of kthread call it uthread.  That the user
>> mode helper code would use to launch a new process.
>> 
>> Anything else and I expect we will be tearing our hair out for the rest
>> of our lives with weird corner cases or unexpected semantics.
>
> Could you give examples of weird corner cases or unexpected semantics?

I gave a couple and it is the classic problem with suid executables
where a lot of unexpected things are inherited from the environment, and
so things become a never ending race.  We replaced daemonize in the
kernel with just forking processes from kthreadd for this very reason.
There was always something else that needed to be reset to make a
process a proper kernel thread.

Eric