Restic mount does not respect permissions

Getting Help
1

I created a test backup of some home folders running:
sudo restic -r rest:http://backup:8000/rtest /home/jc/Desktop /home/bigeddie/Documents

when I mount the back up
restic -r rest:http://backup:8000/rtest mount /tmp/restic

I can view and access all file from both jc and bigeddie. I was expecting to only be able to access jc files and not bigeddie.
Why does it not respect user permissions, or what am I doing wrong?

2

I’m sorry if I’m missing something obvious here, but if you are concerned about being able to read the other user’s files, then your concern should be at the step where you are able to back those files up (i.e. read them) in the first place, no?

If you were able to read the files and thereby back them up, then naturally restic lets you read them from the repository as well. If you should not be able to read one of the user’s files, then that restriction should happen before restic is able to read them, i.e. with proper file permissions.

3

I assume you mean that you can view all files as user jc, who shouldn’t have view permission for bigeddie files (i.e. file permissions aren’t being restored)? A couple of potentially naive suggestions:

  1. What happens if you mount with sudo?

  2. What version of restic are you running? This bug report might be relevant, which appears to have been fixed in 0.12

4

If the user has access to read and thereby back up a given set of files, then those files will be accessible in the repository too. That’s expected.

5

Agreed @rawtaz , however @jjgalvez ran the backup as root. Unless I’m missing the point, the question is about certain users, not root, subsequently seeing each other’s data in a mounted repo.

If original permissions excluded certain users from seeing certain directories, then shouldn’t that restriction still be the case when data are restored or mounted?

6

@Nev I am running restic 0.12.1 compiled with go1.17.3 on linux/amd64
if I run restic mount with sudo then I have to add --allow-other=true to see any files, and then I can only see jc’s files not bigeddie’s as I would have expected

7

@Nev and @rawtaz correct the backup was run as root so obviously add the user data was backed up. The thing I found odd was when I mounted the backup as a normal user (jc) I could see user data that I ordinary should not have access too.

8

@jjgalvez , that behaviour all seems to makes sense:

  1. If you have the repo password, you have access to everything in the repo
  2. So, when mounting as a normal user (jc), you can access all data, but don’t have the ability to chown to bigeddie, so permissions can’t be fully restored and everything remains owned by jc
  3. The only way you can restore permissions is to mount/restore as a user (such as root) who is able to change permissions accordingly.

I guess maybe you were hoping/expecting that there were some sort of user access restrictions implemented in the repo itself? Which there aren’t.

9

@Nev thank you for the clarification. I was wondering if that was iinfact the case, but hadn’t had time to test it properly yet. now it makes sense. I will have ti either 1) rethink my backup strategy or simply work with how restic operates. At least now I know it’s not an error or something I was doing wrong

10

That is currently not a design goal/feature of restic - if a user has access to read the repository, then they can read the files and data in it :slight_smile:

11

When data is restored, the permissions are restored as well. For that, usually you’ll need root privileges.

The fuse mount is an on-demand representation of what’s in the repository. If you (the user account running restic mount) can read the data in the repository, the restic process can read it as well and presents it as a virtual file system. As with most fuse-based file systems (e.g. sshfs), permissions are not checked by the kernel by default.

Be careful who you give access to the fuse mount :slight_smile:

1 Like