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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel