I have a case where I need all repository files to be group-readable (750 directory permissions, 640 file permissions) but restic and the REST server both appear to create with 700/600 permissions instead. There doesn’t seem to be an option to change this behavior. Am I missing something?
Indeed, that’s hard-coded in the source code for now. What’s your use case?
I want to have an off-site host be able to pull backups from the backup server, using
rclone copy --immutable (disallow changes, do not accept deletions).
I don’t want the backup server to be able to write to an off-site server, as an attacker could sabotage the off-site data, but I also don’t want the off-site server to have write permission to the repository either.
The best solution appears to be having the off-site server have SFTP access to the backup server, but with a user that only has read access. The standard way to implement this on Linux is put them in a group with read access, but if restic creates everything 700/600 then this is not possible, unless I have a regularly-scheduled process come along and fix up the permissions just before the off-site server tries to pull from it.
Wouldn’t it be sufficient to have restic just create the files and let the user choose the permissions with an appropriate umask? The data is encrypted anyway.
For the REST server, we’d just add a
UMask option to the systemd service.
I was also hoping to rsync a restic repo off as an unprivileged user (to work around the fact that restic can’t yet “pull” backups).
I guess I’m going to have to play doas (openbsd’s sudo-a-like) games.
An issue for this was created on GitHub.
I’m not sure I completely understand, but could a reverse sshfs mount with the read-only flag set work for this? ( Basically you’d share the sftp server as your main user from the main server without sharing credentials or write access. I’m not completely sure of the security implications of this, but I think this link goes into it. ) For a tutorial, see: https://blog.dhampir.no/content/reverse-sshfs-mounts-fs-push
Sorry if I’m misunderstanding,
I Hope you figure it out!
I’m not sure if that would work but I’m not totally comfortable allowing the backup server to connect to the off-site storage; I’d much prefer that the connection run the other way. Allowing inbound connections to the off-site storage increases the attack surface of that system.
My current solution is to have a cronjob that runs regularly chmod’ing everything to the repository to 750.