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.