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@xxxxxxxxxxxxxx> wrote:
On Sa, 27.02.21 11:28, Rodny Molina (rodnymolina@xxxxxxxxx) 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
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
