Change permissions on repository files

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.

Hi cdhowie,

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!

  • jedi453

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 in the repository to 750.

1 Like

I’m stuck with the same problem. I guess for now I’ll have to implement a cronjob like you. Cheers!

There is another solution… presumably restic doesn’t know or care about ACLs. The following command on the repository root should set up permanent read access for another user ($OTHERUSER):

setfacl -dR -m u:$OTHERUSER:rX $REPO
setfacl -R -m u:$OTHERUSER:rX $REPO

This is untested, but it should work; the default ACL set in the first command should be automatically inherited by newly-created filesystem objects within the directory tree.

Unfortunately, it doesn’t - at least in my scenario.
All new files created by the REST server end up with an empty mask:

getfacl 21b7e6ebfb272f353accf70bec6e625bc16a734588a6c3de6a5076824430c048
# file: 21b7e6ebfb272f353accf70bec6e625bc16a734588a6c3de6a5076824430c048
# owner: restic-rest
# group: restic-rest
user::rw-
user:rsync:r-x                  #effective:---
group::---
mask::---
other::---

Does anyone have a good workaround (except doing a setfacl -R -m m::rX $REPO after each backup)? In my case, I perform a backup of my clients locally to a REST server via restic and want to rsync the backups to another location.

Before testing, I set the ACLs like this:

setfacl -Rm u::rwX,g::0,o::0,m::rX,u:rsync:rX ./*
setfacl -dRm u::rwX,g::0,o::0,m::rX,u:rsync:rX ./*

Thanks!

Hey, I’m stuck with the same problem, as I want to sync repositories stored by rest-server to a remote location as a different user.

Running as a systemd service, I tried to add UMask=027 to the service file (see systemd example), but this did not change anything, files are still created with file access attributes 600 (and 700 for folders). Has anyone checked this or can verify that it does/does not work?

Tested it with rest-server 0.10.0 on a Debian 10.

Edit: For now, I’m stuck with doing chmod before each sync, as also described here:

  • find . -type d -exec chmod g+rx {} \;
  • find . -type f -exec chmod g+r {} \;