Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

From: Stanislav Kinsbursky
Date: Thu May 23 2013 - 07:38:47 EST

23.05.2013 15:31, Jeff Layton ÐÐÑÐÑ:
On Thu, 23 May 2013 14:35:53 +0400
Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> wrote:

23.05.2013 14:00, Eric W. Biederman ÐÐÑÐÑ:
Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> writes:

22.05.2013 21:33, Eric W. Biederman ÐÐÑÐÑ:
Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> writes:

Usermode helper executes all binaries in global "init" root context. This
doesn't allow to call a binary from other root context (for example in a
Currently, both containerized NFS client and NFS server requires an ability to
execute a binary in a container's root context. Root swap can be done in
"init" callback, passed by UMH caller.
But since we have 2 callers already (and more of them are expected to appear
in future) and because set_fs_root() in not exported, it looks reasonable to
add one more generic UMH helper to generic fs code.
Root path reference must be hold by the caller, since it will be put on UMH
thread exit.

Awesome. With this patch as an uprivilieged user I get to pick which
binary the kernel will execute. At least if nfs and nfsd ever runs in a
user namespace (something that looks like only matter of time).

Not really. Only by using a kernel module to call the UMH.
And an unprivileged can't load a module as far a I know.
I.e. NFSd, for example, will use unprivileged user's root to perform this call.

To help me understand the context which instances of call user mode
helper are you expecting to use this facility?

Ok. Here is how the NFSd uses UMH:
UMH is used on NFSd service to start user-space client tracker daemon
("/sbin/nfsdcltarck"), which is used to store some per-client locks data on
persistent storage.

I think this is a seriously bad idea.

Why can't we do this in userspace with setns as we do with the core dump

Could you, please, clarify, how setns can help here?

setns can change the mount namespace, and chroot can change to root
directory in the specified mount namespace. Essentially you can enter
into a containers complete context (pid, mnt, root, etc) comming from
the outside.

So, you are actually suggesting to move the binary start from the kernel to user-space.
IOW, you are suggesting to do not using UMH at all.
Am I right?
I don't know the reasons, why it was done by using UMH and not in userspace.
Could you clarify this, Jeff?

nfsdcltrack is a "one-shot" program for managing and querying the nfsd
client tracking database. When knfsd needs to query or modify the
db, it uses the UMH infrastructure to call this program that does
what's requested and then exits.

So, I'm not sure I really understand your question. It wasn't done in
userspace since the whole purpose of this program is to handle upcalls
from the kernel.

The question is what was the reason to start this binary from kernel by UMH?
I.e. why it can't be started by some user-space process before or after NFSd start?
I don't familiar with this client tracking facility and that's the only reason why I'm asking.

Best regards,
Stanislav Kinsbursky
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at