Re: bind-mount of /run/systemd for chrooted bind9/named

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On So, 09.07.23 20:14, Marc Haber (mh+systemd-devel@xxxxxxxxxxxx) 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@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@drop:~ $
>
> and
>
> 1 [9/5031]mh@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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux