Module container_mounts 

The guest’s container mount table: the mounts /proc/<pid>/mountinfo and /proc/<pid>/mounts show, which hermit-cli builds once, in the completed container namespace before the guest starts, and Detcore renders on every backend (package K slice K3a, https://github.com/rrnewton/hermit/issues/4213).

A container’s mount namespace starts as a copy of the host’s, so a table read from the kernel has a row for every host mount that existed when Hermit started: other users’ FUSE checkouts, other agents’ bind mounts, logind’s /run/user/<uid>. Which of those exist changes from one run to the next, and a row added or removed renumbers every row after it. The table below shows only the mounts a fixed rule selects (ContainerMountTable::select), so host mounts outside that rule, made or removed between two runs, change nothing the guest reads.

The rows the rule shows are still host facts where they are host mounts:

• the base mountpoints;
• the host mounts above a mount Hermit installed (rule 3). A mount Hermit stages below /tmp is installed first in its private tmp directory, below $TMPDIR or --tmp, so rule 3 then shows the host mount holding that directory too;
• the copies a recursive bind of the plan makes of the host mounts below its source (every user --bind and --mount type=bind of a directory is recursive), which are the bind’s own rows (rule 1), ephemeral seeds included, so they come and go with the host’s mounts below that source.

The kernel lists mounts in creation order (by unique mount ID since Linux 6.8, in attach order before). The host rows are the copies made when the container’s namespace was created, so a host remount moves no row; only a host unmount and a new mount at a shown row’s path, between two runs, moves that row.

Structs

ContainerMount

One row of the guest’s mount table: every field of a Linux /proc/<pid>/mountinfo line, as the kernel wrote it in the completed container namespace (paths and the source escaped as the kernel escapes them), except the parent, which names the nearest mount the table shows (ContainerMountTable::select). Mount IDs, devices and peer groups are the kernel’s raw values; Detcore numbers them for the guest through the same pools that number stat, statx and fdinfo.

ContainerMountTable

The guest’s container mount table (see the module documentation).

Installation

One installation of the container’s mount plan, as hermit-cli recorded it while installing it, in the completed namespace before the guest starts.

Constants

BASE_MOUNTPOINTS

The mountpoints the guest sees whenever its container has a mount at one: the filesystems every Linux program may expect to find, modelled on the minimal machine of gVisor’s /proc. A host mount at any other path is hidden unless it holds a mount Hermit installed (ContainerMountTable::select).

Functions

assign_installed_rows

Assign each row the plan created to the installation that created it, for a plan installed as the namespace’s last mounts, one mount operation after another, in a namespace whose propagation from the host was cut (made private) before the plan’s first mount, so that no host row can follow it: namespace lists rows in creation order (the kernel’s row order), so the plan’s rows are its end, each installation’s together and in plan order, each starting with the one row the operation created at its target (a recursive bind’s copies of the mounts below its source follow it). Walking back from the last row, a row is

check_installed_rows

Refuse a walk (assign_installed_rows) whose result does not show the plan as installed: every installation that creates a row (one with a mountpoint) must have been given a row at its own recorded target, and the row given to the first installation must be the container’s own /proc (is_plans_first_row; a copy of the host’s /proc, at the same path but earlier, would mean the walk ran past the plan into the host’s rows). The reason names the first installation that fails.

owned_mounts

The rows of namespace the installations made, split into Hermit’s (the plan’s own: rule 1 of ContainerMountTable::select) and a backend’s own. A created row counts only at, or below, a mountpoint its installation names, so no row a later mount’s symbolic link redirects a path onto can be taken for an installation’s. A recursive bind’s copy of a mount below its source takes the owner of the row it copies: a backend’s own mount staged below Hermit’s private tmp directory stays a backend’s in the bind of that directory over /tmp.

parse_container_mounts

Parse a Linux /proc/<pid>/mountinfo snapshot into its rows, in the grammar crate::procfs::parse_mountinfo accepts: None for a malformed row, an optional field this crate cannot map, or a repeated mount ID.