Hi,

Jonathan Dowland writes:
> I just wrote a blog post about how to use Systemd to configure mount-on-demand
> filesystems, e.g. /backup (in my case). This was triggered by recent news in
> the UK that a major hosting provider had deleted all their customer VMs by
> accident by issuing something like "rm -rf" - but they *also* got all their
> backups because their backup volume was mounted too.
>
> Anyway, in the past I've read some useful tips for using Systemd on this
> list, so here's the blog post should it be of any interest:
>
> https://jmtd.net/log/mount_on_demand_backups/

I think using mount namespaces is a bit nicer solution for the problem:
the /backup mount will only be visible for the backup process and, as
far as I understand, be automatically unmounted when all processes in
the namespace exit, i.e. when the backup is done.

Here is a quick example in an interactive shell:

+---
| # umount /boot; ls /boot
| [empty]
| # unshare -m
| [Note: This will start a subshell]
| # mount /boot; ls /boot
| System.map-4.3.0-1-amd64 [...]
| [Run backup here ;)]
| [Note: /boot will appear empty for other processes at this point.]
| # exit
| # ls /boot
| [empty]
+---

I used /boot instead of /backup as that exists on my computer.

Note that /boot is only visible from the subshell started by unshare or
other processes that entered the namespace (e.g. with nsenter(1)).  A
stray `rm -rf /` can thus not see it even when run at the time of the
backup.

I'm not sure you can achieve this via systemd's .mount units, although
systemd itself also makes use of mount namespaces.  For example, systemd
uses them to provide a per-service /tmp, make /home unaccessible or only
allowing read-only access to /usr or /etc for individual service.  See
the PrivateTmp=, ProtectHome=, ProtectSystem=, PrivateDevices=,
ReadOnlyDirectories=, InaccessibleDirectories= and ReadWriteDirectories=
in man:systemd.exec(5).

Ansgar

Reply via email to