[systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Lennart Poettering
lennart at poettering.net
Mon Jul 10 08:28:52 UTC 2023
On So, 09.07.23 20:14, Marc Haber (mh+systemd-devel at zugschlus.de) wrote:
> > It should suffice bind mounting just the notify socket, not the full
> > dir.
>
> Is it intended behavior that an empty file is left at the "mount point"
> (what Where= points to) after the unit was stopped?
We need an inode we can overmount, and given that this is in /run/
(hence inherently ephemeral) and a fixed path it shouldn't matter.
> > 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).
>
> I do not quite understand exactly what that means, how would I do that?
> What is "this" in the "mount this" part of sentence?
use BindPaths= to mount the notify socket to the right place.
> > 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.
>
> Where would I read up on systemd namespacing? Are you refering to what
> is explained in the "Sandboxing" chapter of systemd.exec(5), like
> ProtectSystem, ReadWritePaths etc?
yes.
> So I would basically set
> ProtectSystem=strict
> ReadWritePaths=/var/local/chroot/bind/pathlist (all paths that bind
> needs to actually write to) and then finally
> ExecStart=/path/to/bind -f -t /var/local/chroot/bind ?
I don't know bind, so can't judge on the command line, but otherwise, yeah.
> If I set ProtectHome=yes, how do I give the user that bind runs as
> access to its homedir? Is ReadWritePaths= the solution?
ProtectHome= is about /home/ only, i.e. regular ("human") users, not
about system users (i.e. uid < 1K). Your bind should *not* run as
regular user, but as a system user of course, hence ProtectHome= is
something you can just set, and don't need to be concerned about the
system user's home dir.
> > > 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.
>
> StopWhenUnneeded was what I needed. So I currently have:
>
> [7/5031]mh at drop:~ $ sudo systemctl cat named
> # /lib/systemd/system/named.service
> [Unit]
> Description=BIND Domain Name Server
> Documentation=man:named(8)
> After=network.target
> Wants=nss-lookup.target
> Before=nss-lookup.target
> RequiresMountsFor=/var/local/chroot/bind/run/systemd
>
> [Service]
> Type=notify
> EnvironmentFile=-/etc/default/named
> ExecStart=/usr/sbin/named -f $OPTIONS
> ExecReload=/usr/sbin/rndc reload
> ExecStop=/usr/sbin/rndc stop
bind doesn't react to SIGTERM correctly on its own?
> Restart=on-failure
>
> [Install]
> WantedBy=multi-user.target
> Alias=bind9.service
> [8/5030]mh at drop:~ $
>
> and
>
> 1 [9/5031]mh at drop:~ $ sudo systemctl cat var-local-chroot-bind-run-systemd.mount
> # /etc/systemd/system/var-local-chroot-bind-run-systemd.mount
> [Unit]
> StopWhenUnneeded=true
>
> [Mount]
> What=/run/systemd
> Where=/var/local/chroot/bind/run/systemd
> Type=none
> Options=bind
Note that /run/ should always be a tmpfs, hence unless you mount a
tmpfs to /var/local/chroot/bind/run/ first, the above is a bit ugly.
Instead of this .mount unit, consider using in the .service file:
TemporaryFileSystem=/var/local/chroot/bind/run
BindPaths=/run/systemd/notify:/var/local/chroot/bind/run/systemd/notify
(Under the assumption bind chroots itself into /var/local/chroot/bind)
Lennart
--
Lennart Poettering, Berlin
More information about the systemd-devel
mailing list