[systemd-devel] avoid unmounts in unprivileged containers

[Rodny Molina]

Right, in systemd's case there's no access to the external namespaces, but
being the first process in a container allows you to take a snapshot of
/proc/1/mountinfo during initialization (the container runtime would have
all the initial mountpoints ready by then), and store all these mountpoints
and their parameters in a hash-map. That way, when an unmount arrives, you
just need to compare it with your mountpoint DB to determine if they are
"foreign" or "local".

In our particular case (Sysbox container runtime) the above simplistic
approach was not enough coz, on top of the above, we also needed to prevent
certain remount operations (read-only -> read-write) from succeeding ...

Hope it makes sense now.

cheers,

/Rodny



On Mon, Mar 1, 2021 at 1:29 PM Lennart Poettering <lennart at poettering.net>
wrote:

> On Sa, 27.02.21 11:28, Rodny Molina (rodnymolina at gmail.com) wrote:
>
> > Thanks for your detailed answer / explanation Lennart, it's fully
> > consistent with my code-browsing findings.
> >
> > I've been struggling myself with the problem that you alluded above to
> > identify "foreign" mountpoints. After banging my head against the wall
> for
> > a while i ended up implementing an heuristic based on the
> > major:minor-number field of the /proc/pid/mountinfo file: if the
> container
> > mountpoint being considered has a major:minor-id that matches those
> > major:minor-ids present in the host mount namespace, then this one is
> > likely a "foreign" mountpoint, and shouldn't be unmounted.
>
> Not sure I follow. We'd need this from inside the container, so that
> we don't even try to unmount the file system. But from "inside" we
> have no outside to the host mount namespace...
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>


-- 
/Rodny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210301/11ec2907/attachment.htm>