add non-root deployment strategy

[stephan13360]

Add a deployment strategy describing how to run borg as a non-root user and still be able to access/backup all files on the system.

I was not sure if I should include more about how/where to create the systemd service and timer files. I feel like this would not be the place to explain basic systemd, so I kept it short. If someone feels different, I could add more detail.

[NetSysFire]

Congratulations on your first PR. Have your first review, too! :p

[ThomasWaldmann]

Looks pretty good!

How would one extract system files from such a repo, preferably without messing up repo permissions?

[stephan13360]

Ah yes, good question.

I mount the repo as root and not the non-root user, when restoring files, since as you say yourself, you would not be able to open system files otherwise.

That should probably also be included in the description. Let me get right on that.

[ThomasWaldmann]

Can you check the files in the repo after doing that: is anything then owned by root rather than the non-root user?

[stephan13360]

Using borg extract or borg mount and then a tool like rsync -a both work and keep the correct permissions.

root@emily:~/restore# borg extract backup:/volume2/borg/emily.nuxio.de::emily.nuxio.de-2024-02-21-02:34 srv
root@emily:~/restore# ls -l srv/acme/
total 252
-rw-rw-r-- 1 acme acme    461 Feb  5 00:00 account.conf
-rwxr-xr-x 1 acme acme 222822 Feb  5 00:00 acme.sh
-rw-r--r-- 1 acme acme     68 Apr  4  2023 acme.sh.env
drwxr-xr-x 3 acme acme   4096 Apr  4  2023 ca
drwxr-xr-x 2 acme acme   4096 Feb  5 00:00 deploy
drwxr-xr-x 2 acme acme   4096 Feb  5 00:00 dnsapi
drwxr-xr-x 3 acme acme   4096 Jan 28 00:00 dot.nuxio.de_ecc
-rw-r--r-- 1 acme acme   1307 Feb 21 00:00 http.header
drwxr-xr-x 2 acme acme   4096 Feb  5 00:00 notify

root@emily:~# borg mount backup:/volume2/borg/emily.nuxio.de::emily.nuxio.de-2024-02-21-02:34 restore/
root@emily:~# rsync -a restore/srv/acme .
root@emily:~# ls -l acme/
total 252
-rw-rw-r-- 1 acme acme    461 Feb  5 00:00 account.conf
-rwxr-xr-x 1 acme acme 222822 Feb  5 00:00 acme.sh
-rw-r--r-- 1 acme acme     68 Apr  4  2023 acme.sh.env
drwxr-xr-x 3 acme acme   4096 Apr  4  2023 ca
drwxr-xr-x 2 acme acme   4096 Feb  5 00:00 deploy
drwxr-xr-x 2 acme acme   4096 Feb  5 00:00 dnsapi
drwxr-xr-x 3 acme acme   4096 Jan 28 00:00 dot.nuxio.de_ecc
-rw-r--r-- 1 acme acme   1307 Feb 21 00:00 http.header
drwxr-xr-x 2 acme acme   4096 Feb  5 00:00 notify

Both times the files a correctly owned by the user acme and not by root.

I think, the repo itself should not be able to know if root or a non-root user with the CAP_DAC_READ_SEARCH capability created the backup.

Anything else I should consider / test / add to the document?

[ThomasWaldmann]

In case of using a remote repo with an explicit user given (like ssh://borg@backupserver/...) there is no problem, because it will always be that user that accesses the repo.

With a local repo, it will use the current user, so that will vary between root and non-root in this case, which might lead to a mixup of file owners in the repo.

[ThomasWaldmann]

There is the trick to use ssh://borg@localhost/... one could use for the local case to avoid such issues.

[stephan13360]

I just tested that. I wasn't even aware local repos without ssh are a thing :-)
It seems like everything is fine. At least when using the root user only to restore / mount the repo.

I created a repo with a non-root user. Run an initial backup and then used root to restore the same srv directory as before.
I then checked the few files in this new repository, and all are owned by the non-root backup user.

I would say to be sure I will add a warning block in the docs that when using the root user and a local repo, care has to be taken not to use any functions that modify the repository but restore and mount are fine.

[ThomasWaldmann]

LGTM!

[ThomasWaldmann]

@stephan13360 could you forward port this to master branch?

if you like, it could be also backported to 1.2-maint branch, but this is rather of short term interest, because soon 1.4.x will supersede 1.2.x.