Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

From: Stanislav Kinsbursky
Date: Thu May 23 2013 - 04:08:39 EST

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.

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?

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.

This patch as it stands looks like it would compete for the honor of the
easiest kernel feature to exploit.

As far as I can see (maybe I'm missing something), there main security issue that could be here
is allowing of using any passed root to swap to.
What about using the current root instead of passed one? I.e. taking the root to swap to inside the UMH.
Does this keeps the isolation on the same level?


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