Module nested 

Nested proot and bwrap: a view of their own instead of a supervisor of their own.

The kernel allows one tracer per process and one seccomp listener per filter chain, so a proot started inside the guest could never supervise anything. It does not have to: the supervisor already serves every descendant, and all a nested launch needs is a different translation table for one subtree. So an execve of the supervisor’s own binary, or of any ELF named proot or bwrap (the latter unless PROOT_NEST=0), is not carried out. The command line is parsed here, on the tracee’s behalf, with the tracee’s view, working directory, environment and descriptors; every path in it is composed through that view into a View in host terms, which the process enters at the exec of the real command and its descendants inherit. The process that called proot becomes the command, so the caller’s child, exit status and signals are the kernel’s own.

What only the process itself can do (chdir, setsid, the death signal, the caller’s seccomp programs, the status descriptors, a replaced environment, a usage message on its own stderr) is handed to the exec trampoline through its record, see super::shim.

A nested view can see no more than the view it was asked from: -r / inside a guest is that guest’s root. Options that would change which syscalls the filter notifies (-0, -k) cannot be served unless the outer launch already notifies them, and are refused with a message.

Structs

Tracee 🔒

The requesting tracee, as the command-line parsers see it.

Enums

EnvSource

Where a nested launch takes its environment from.

FrontEnd

Which command-line dialect a nested launch speaks.

Constants

MAX_ENV 🔒

Upper bound on environment entries read from the tracee.

NAMES 🔒

Program names intercepted by name (the supervisor’s own binary is intercepted by inode, whatever it is called).

Functions

by_name_enabled 🔒

Whether programs named proot or bwrap are intercepted; PROOT_NEST=0 turns it off.

compose_sub_bindings 🔒

Adds what the nested command line asks the trampoline to do before the exec.

detect

Decides whether an exec is a nested launch, and in which dialect.

dev_ino 🔒

Device and inode of a host path, symlinks followed.

executable 🔒

execve’s own checks on a host path: it exists, is not a directory, and is executable.

merge_setup 🔒

A plan that already carries a trampoline (a launch nested inside the nested one) keeps the innermost view and gets the outer launch’s process setup on top; the innermost environment wins when both set one.

nested_cwd 🔒

The working directory the nested command starts in, as a guest path of the nested view, and a warning when it is not the one asked for.

plan

Plans a nested launch: the command of the nested command line, run in a view composed from the requester’s.

read_env 🔒

Reads the tracee’s environment as (name, value) pairs.

resolve_command 🔒

The guest path of the nested command: as given when it has a slash (relative to the nested working directory), else found in PATH.

same_file_as_us 🔒

Whether host is the file the supervisor itself is running from.