Comment by innocent_name
11 hours ago
>Motivated by our success in developing this solution, we try to use it to backup the homelab with its 10 Docker containers. But later we find out from logs on the individual machines that backups are failing. The reason being that many Docker containers like to create root-owned files, and if you’re not careful you can create a cronjob running as the default user.
and a privesc also.
The ideal setup is rootless Podman and having all your containers not even be able to create root-owned files.
It would also be great if services did their own database dumps. Immich does this and it's such a relief to just be able to copy over its volume for backup purposes.
Unfortunately we don't live in an ideal world and so much of the software both doesn't dump it's own databases, and is incapable of running in a rootless container.
If you weigh the probability of a privesc from your backup with full access to the volumes, against the probability that the software you run has a CVE, which one is worse?
This is one of those things I consciously chose to ignore in my setup. Maybe it will come back to bite me in the future, sure. Or maybe I will learn a better approach that pushes my frontier of convenience-security forward.
Yeah it feels it can be risky to "make the backup also dump the databases, and give it full filesystem permissions on our Docker volumes", depending on what binaries get the root privileges.
What I do is having a minimal systemd timer under root that only calls restic for backing up files (with some additional systemd seucurity restrictions). App-dependent backup logics, like dumping databases, are done by user/container-level cronjobs separately.