Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

[Stanislav Kinsbursky <skinsbursky@parallels.com>]

23.05.2013 15:31, Jeff Layton пишет:
> On Thu, 23 May 2013 14:35:53 +0400
> Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
>
>> 23.05.2013 14:00, Eric W. Biederman пишет:
>>> Stanislav Kinsbursky <skinsbursky@parallels.com> writes:
>>>
>>>> 22.05.2013 21:33, Eric W. Biederman пишет:
>>>>> Stanislav Kinsbursky <skinsbursky@parallels.com> 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?
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