[systemd-devel] namespace problem

[Demi Marie Obenour]

On Fri, Jul 19, 2024 at 12:08:58AM +0300, Mantas Mikulėnas wrote:
> On Thu, Jul 18, 2024, 15:43 Thomas Köller <thomas at koeller.dyndns.org> wrote:
> 
> > Am 18.07.24 um 14:04 schrieb Mantas Mikulėnas:
> > > Yes, but namespace persistence actually relies on filesystem access –
> > > it's implemented as a bind-mount of the namespace file descriptor (onto
> > > /run/netns for the 'ip netns' tool), as otherwise namespaces only exist
> > > as long as processes that hold them.
> > >
> > > So if you have any service options that cause a new *mount* namespace to
> > > be created (preventing its filesystem mounts from being visible outside
> > > the unit), then it cannot pin persistent network namespaces.
> >
> > Quoting the manual page:
> >         ProtectSystem=
> >             Takes a boolean argument or the special values "full" or
> > "strict". If true, mounts the /usr/ and the boot loader directories
> > (/boot and /efi) read-only for processes invoked by this unit. If set
> >             to "full", the /etc/ directory is mounted read-only, too.
> >
> > No mention of /var or /run.
> 
> 
> It still works this way whether it's mentioned or not. Once the unit's
> process is put in a new mount namespace, the entire `/` is marked private
> so that any mounts made underneath `/` remain visible only in that
> namespace. This equally affects the "read-only /etc" mount done by systemd
> itself as well as the /run/netns mount done by 'ip' or any other mounts
> done anywhere else.

This still ought to be mentioned in the documentation.  Not everyone
knows that persistent network namespaces involve bind mounts, and it is
much better for the caveat to be mentioned in the manual pages.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240719/0e3c8c98/attachment.sig>