Restic backup app fails with warnings about priviliges and missing log file

Support apps
, , ,
1

What type of hardware are you using: Old laptop or computer
What YunoHost version are you running: 12.0.17
What app is this about: Restic backup

Describe your issue

Hi yunohost forum! I installed yunohost last week, and I am really liking using yunohost so far, it’s a great system. Unfortunately I hit a snag with the restic backup app.

I’m trying to set up an automated backup system for my yunohost instance. As a first step, I figured I’d install the restic app and get it to backup to a local folder (perhaps /ResticBackups or somewhere similar. Backup up to external storage is the next step.).

When running the restic, execution fails with a bunch of warnings about sudo creating new permissions and then a failure exit code (see included logs).

When installing the restic app, essentially the only setting I’ve changed at all is the destination dir. Some destinations I tried:

  • /tmp/ResticBackups
  • /home/yunohost.backup/ResticBackups
  • /home/bobrubbens/ResticBackups, with the ResticBackups dir pre-made through SSH before installing the app. I set the permissions for that folder fully to the restic user after installation of the restic app, but before running the restic service.

My yunohost install at this point is pretty vanilla. I have Immich, Navidrome, Filebrowser and Roundcube installed, and did not do any customization, beyond using the yunohost web api, at all.

I’ve also tried re-installing the restic app a bunch of times, and I tried restarting the server a few times, and also doing a system (apt) update through the web UI. The error is still there. Not even a folder ResticBackups is created.

Any ideas? I’m happy to do further debugging, but at this point I’m just lost on how to continue. I’d prefer to keep using restic, as it seems there are nice cheap storage options available, but if the package will remain broken in the long term perhaps I should consider borg, or maybe the builtin backup facilities + a custom restic script…?

As a side question: I’ve found very few sources/examples on how to restore backups made with the restic app. I was hoping I don’t have to copy/rsync files myself, but can instead just click in the yunohost web interface to “import” a backup… Is that the case? I’d be happy to write a blog post about it once I figure it out, if someone can point me in the right direction…? In any case, I’ll settle for getting restic working in the first place if it comes down to it :-).

Share relevant logs or error messages

2

Well, I’m stumped. I executed the /var/www/restic/backup-with-restic script as root, and it created a backup that seems to match the size of the data I want to back up without problems. Furthermore, switching to root with sudo -s and then running the backup-with-restic script as the restic user as follows:

sudo -u restic /bin/bash -c /var/www/restic/backup-with-restic

Also works perfectly (I did have to edit /etc/sudoers.d/restic to temporarily allow the restic users to execute /bin/bash commands, so maybe I fixed it by giving way too many permissions?).

In any case, it seems that the problem is somewhere in the interface between systemd and the entry point of the backup script, but I don’t know which way to continue now.

3

From what I’ve seen while browsing the package sources, there seems to be no support for this. All code seems aimed at getting restic to make a backup, with none aimed at restoring backups…

4

I’ve made some progress. Apparently the standard systemd unit for the restic app has some security hardening settings. It might happen that these hardening settings forbid the systemd unit to write to the home directory, or possibly to other places on the system. When I commented out the hardening settings, the service started doing its thing.

So I guess the use case of doing it locally is, perhaps accidentally, not supported by the restic package. I guess we can add a write excemption if the target backup path is a local path, maybe?

In the short term, I just need to figure out which of these settings it is:

### Depending on specificities of your service/app, you may need to tweak these
### .. but this should be a good baseline
# Sandboxing options to harden security
# Details for these options: https://www.freedesktop.org/software/systemd/man/systemd.exec.html
# NoNewPrivileges=yes
# PrivateTmp=yes
# PrivateDevices=yes
# RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
# RestrictNamespaces=yes
# RestrictRealtime=yes
# DevicePolicy=closed
# ProtectClock=yes
# ProtectHostname=yes
# ProtectProc=invisible
# ProtectSystem=full
# ProtectControlGroups=yes
# ProtectKernelModules=yes
# ProtectKernelTunables=yes
# LockPersonality=yes
# SystemCallArchitectures=native
# SystemCallFilter=~@clock @debug @module @mount @obsolete @reboot @setuid @swap @cpu-emulation @privileg>

# Denying access to capabilities that should not be relevant for webapps
# Doc: https://man7.org/linux/man-pages/man7/capabilities.7.html
# CapabilityBoundingSet=~CAP_RAWIO CAP_MKNOD
# CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_AUDIT_WRITE
# CapabilityBoundingSet=~CAP_SYS_BOOT CAP_SYS_TIME CAP_SYS_MODULE CAP_SYS_PACCT
# CapabilityBoundingSet=~CAP_LEASE CAP_LINUX_IMMUTABLE CAP_IPC_LOCK
# CapabilityBoundingSet=~CAP_BLOCK_SUSPEND CAP_WAKE_ALARM
# CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG
# CapabilityBoundingSet=~CAP_MAC_ADMIN CAP_MAC_OVERRIDE
# CapabilityBoundingSet=~CAP_NET_ADMIN CAP_NET_BROADCAST CAP_NET_RAW
# CapabilityBoundingSet=~CAP_SYS_ADMIN CAP_SYS_PTRACE CAP_SYSLOG
5

It’s probably a combination of two or more of the flags…

6

I don’t have the time to figure out which pair (or triplet, quadruplet, etc.) of options causes this problem, and I really need to get a local backup going, so for now I’ve settled for just removing all the hardening options, after regular installation in the YunoHost web UI, using:

$ sudo systemctl edit --full restic.service

(Just put # characters before the hardening options)

I know this is a pretty bad idea, but since it’s more or less an internal script, I think is hould be safe for the short term. I plan on actually debugging the problem and maybe submitting a PR to the Yunohost Restic package since I don’t like the feeling of leaving my server in this hacky state. No clue when I’ll find the time for it, though…

Regarding restoration of backups: when the yunohost restic backup runs, it creates a hierarchy of folders for each part you’ve set yunohost restic to backup. So in my test case, I’ve set it to back up the config and one app, let’s call it “some_app”. Under the path I’ve given, say /media/MyBackup/restic, it makes a folder for each component, so now the folder structure looks like this:

/media/MyBackup/restic
  - auto_conf
  - auto_some_app

After eyeballing the files for a bit, I suspect each of the auto_* dirs are independent restic “repos”. So to restore them, I guess you just use the plain restic tool, point it at each of the individual dirs in turns, and copy the contents to / (only do this if you know what you are doing! At the time of writing, I don’t have a clue!). The only missing piece of the puzzle is that, this way, I’m not utilizing Yunohost facilities for restoring backups. So maybe you just need to restore to some temporary folder, and then point yunohost’s restoration system at the path. We’ll see… Maybe it’s just tarballs inside the restic backups. I don’t have time to get to the bottom of this atm. Hopefully this helps anyone with similar questions in the mean time.

7

Hi, you’re right, I wrote an update and I’m waiting for YunoHost App team to get it published… In a few days I hope

8

Thanks for your efforts! I just coincidentally found your issue + PR. For those interested, have a look at issue 35 on the github/YunoHost-apps/restic_ynh repo.

9

The update is ready and you’ll be able to update in a few hours/days!

10

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.