Re: os-release: extension to expose host's version variables to containers

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 16.04.20 16:56, Simon McVittie (smcv@xxxxxxxxxxxxx) wrote:

> 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.

I am not opposed adding something similar to nspawn, using the same
paths. Only issue I see: docker doesn't acknowledge the existance of
/run inside the container iirc, i.e. doesn't pre-mount it, hence
passing data in via some subdir in /run is weird...

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel