On Mo, 03.07.23 20:52, Marc Haber (mh+systemd-devel@xxxxxxxxxxxx) wrote: > (1) go fully systemd > That would mean to get rid of bind's -t option completely but use > systemd's RootDirectory directive instead. I have not tried this but I > think that the bind community might be reluctant to support a setup like > that. In advantage, I could use the BindReadOnlyPaths directive to > directly manage the necessary bind mount to make the notify socket > accessible. I'd generally advise this, as it means you can drop caps like CAP_SYS_ADMIN and so on right-away, i.e. all the stuff that chroot() means. You don't need to explicitly mount the notify socket if you use this btw, systemd will do this for you automatically if you combined RootDirectory= and Type=notify. > (2) try to preserve the classic setup > That would probably mean having a > /etc/systemd/system/var-local-bind-run-systemd.mount with the contents: > | [Mount] > | What=/run/systemd > | Where=/var/local/bind/run/systemd > | Type=none > | Options=bind > | > | [Install] > | WantedBy=bind9.service > and adding a RequiresMountsFor=/var/local/bind/run/systemd to the > bind9.service. It should suffice bind mounting just the notify socket, not the full dir. You could also use a hybrid approach: let systemd bind mount this for your service (and thus set up a minimal namespaced env for your service, but with the root where it normally is), and then still let bind do its own chroot() thing inside of it). Generally speaking: its typically a better idea to rely on proper fs mount namespacing (i.e. decoupling mount tables of services and host) rather than plain chroot() (where they aren't decoupled). If bind only does chroot(), then I think using systemd's namespacing is the much better choice. > This works as intended when I start up bind9, but when stopping the name > daemon, the bind mount still lingers around. I have not fully understood > the necessary systemd magic to have var-local-bind-run-systemd.mount > stopped whenever bind9.service stops. How would I do that? You can do Wants= from bind to the mount unit. And then do StopWhenUnneeded= in the mount unit, to release it when not needed. So, I personally would always lock things down with systemd mechanisms (i.e. systemd-analyze security will help you big time). If the daemon in question then does further lockdown, that's great (as sometimes a daemon might need privs during startup but not later), but generally systemd should be better at locking things down, given the seccomp stuff and all that other stuff it nowadays does. Lennart -- Lennart Poettering, Berlin