On Fri, Jul 19, 2024 at 12:08:58AM +0300, Mantas Mikulėnas wrote: > On Thu, Jul 18, 2024, 15:43 Thomas Köller <tho...@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
signature.asc
Description: PGP signature
