[systemd-devel] os-release: extension to expose host's version variables to containers

[Simon McVittie]

On Thu, 16 Apr 2020 at 14:03:43 +0000, Luca Boccassi wrote:
> But I found at least one other use case where this is needed, and the
> solution there is to add a new directory /host/ which replicates part
> of the host's filesystem tree, including os-release:
> 
> https://docs.netdata.cloud/packaging/docker/#run-netdata-with-the-docker-command
> https://github.com/netdata/netdata/issues/7488

Flatpak uses /run/host for similar things. Some parts of the host system
are visible to Flatpak apps unconditionally, and some only if the Flatpak
app has special permission flags.

In particular, if a Flatpak app has the --filesystem=host permission flag
(which is mainly intended to expose the host's /home, /srv, /media etc. in
the container's /home, /srv, /media etc., for apps that can't be sandboxed
properly), the host's /usr and /etc get exposed in /run/host/usr and
/run/host/etc.

In the Flatpak 1.7 development branch, I added a host-os permission,
which puts the host /usr in /run/host/usr, the host /bin, /sbin and /lib*
(if not /usr-merged) in /run/host/bin etc., and a small subset of /etc
(ld.so.cache, alternatives) in /run/host/etc; and a host-etc permission,
which puts the whole host /etc in /run/host/etc. Those can be used to
share the host OS, without the side-effect of sharing users' personal
files.

/run/host seems like a reasonable convention to encourage for
container/host systems that want this, since it doesn't require
inventing a new top-level directory. The experimental pressure-vessel
container-runner, used in Steam to run games in containers, also uses
/run/host.

That setup would automatically let apps with appropriate permissions read
/run/host/etc/os-release and/or /run/host/usr/lib/os-release to get host
OS properties.

    smcv