[Devel] [PATCH hci-8.1] ve: start the kernel threads of a container in its ve namespace

[Konstantin Khorenko]

On Tue, 03 Nov 2026 04:02:34 +0200, Eva Kurchatova wrote:
> The kthreadd and khelper of a container are forked from a worker that
> takes over the namespaces, root, credentials and cgroups of the task
> starting the container, but not its ve namespace, which nsproxy does
> not carry.

Only kthreadd is forked from the worker. ve_create_kthreadd() points
ve->kthreadd_worker at it for that one fork, then switches to the own
worker of kthreadd, and ve_start_kthreadd() destroys the worker.
ve_start_umh() runs after that, so khelper is forked by the container
kthreadd and inherits the ve namespace from it. Please fix the
sentence, e.g. "The kthreadd of a container is forked from a worker
... Every other kernel thread of the container, khelper included, is
forked from that kthreadd."

> As task_ve follows the ve namespace, they run as host tasks,
> and so do the usermode helpers the container starts: a core dump to a
> pipe in a container fails, because the host may not execute a file
> from an untrusted container disk.

The patch also fixes nfsd in a container. Its threads are created
through the container kthreadd (serv->ve_virtualized), so they had
get_exec_env() == ve0, and nfsd4_umh_cltrack_upcall() passed that to
call_usermodehelper_ve(): the host ran its own nfsdcltrack in the host
root for a client of the container. Worth one sentence, it is a worse
case than the core dump.

> +	/* task_ve follows the ve namespace, which nsproxy does not switch */
> +	switch_ve_namespace(current, get_ve_ns(target->ve_ns));

Optional: "which is not part of nsproxy" is what the comment means.
The FIXME in switch_ve_namespace() and commit_nsset() switch the ve
namespace last, after creds; moving the call after
cgroup_attach_task_all() would keep the two paths alike. Nothing
depends on the order today.

Pasha, could you please review it as well? It changes how the
container kthreads get their task_ve after your 4d033dd01fd3.

With that fixed:

Reviewed-by: Konstantin Khorenko <khorenko at virtuozzo.com>

-- 
Konstantin Khorenko,
Virtuozzo Linux Kernel Team