Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

From: Boaz Harrosh
Date: Thu May 23 2013 - 08:25:50 EST

On 23/05/13 14:58, Stanislav Kinsbursky wrote:
> 23.05.2013 15:56, Jeff Layton ÐÐÑÐÑ:
>> On Thu, 23 May 2013 15:38:17 +0400
>> Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> wrote:
>>> 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
>>>>>>>>> container).
>>>>>>>>> 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
>>>>>>>> helper?
>>>>>>> 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?
>> Manipulating and querying the client tracking database is an infrequent
>> event, so having a continuously running daemon is wasteful and means
>> that the admin has to ensure that it's running. A UMH upcall is much
>> simpler and generally "just works" if the program is present.
>>> 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.
>> This program is not a daemon that runs continuously. It's only called
>> when the kernel needs to manipulate the database. Are you asking
>> whether we could turn this into a continuously running daemon? If so
>> then the answer is "yes", but that's not really a good idea either.
>> In fact, we had that with the nfsdcld program, but no one liked it
>> (including me) for the reasons I detailed above.
> No, I'm just asking to understand.
> Eric was, actually, asking the same. I.e. how does NFSd uses UMH and why this can't be done in userspace?
> Thanks you for your answer.

I'm not familiar with nfsdcltrack but I would imagine it receives it's information from
Kernel as a command line parameters.

Would it not be the simplest approach to add a --chroot=/path/to/root optional
parameter to nfsdcltrack so it should access an alternate DB relative to

This would address Eric's concern of not executing user-privileged executable
from Kernel. I think

Just my $0.017

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