mount: Add default-permissions flag to set FUSE option

[kylewlacy]

What is the purpose of this change? What does it change?

This PR adds the new flag --default-permissions for the mount command, which enables the "DefaultPermissions" FUSE option. This option enforces the Unix permissions of the mounted filesystem. When this flag is disabled, any user can access any file from the restic FUSE mount if the --allow-other flag is set; when enabled, a user can only access a file from a snapshot if they could access it originally.

As a quick demo of this feature, I wrote up a quick gist: https://gist.github.com/kylewlacy/99ec3859955a25dbbb94a56ce1b4de42 (note that it requires root, or at least the ability to run as two different users).

Was the change discussed in an issue or in the forum before?

No (I figured it was easier to discuss this feature by providing this small PR first, then iterating on it if needed)

Checklist

• I have read the Contribution Guidelines
• I have added tests for all changes in this PR
• I have added documentation for the changes (in the manual)
• There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
• I have run gofmt on the code in all commits
• All commit messages are formatted in the same style as the other commits in the repo
• I'm done, this Pull Request is ready for review

N.B. manpage changes need to be regenerated still (I tried regenerating them but there were other changes too, so I figured it would be easier to leave out of this PR for now). I can regenerate the manpages if needed though

I also didn't write any tests for this PR. First, there were no tests for the other FUSE-specific options so I wasn't sure it was warranted, and second, this test would be hard to write since it would involve running at least as a root user and a non-root user. I'd be happy to try my hand at writing some tests if anyone provided some suggestions/ideas for testing this kind of feature

Other notes

I'd be more than happy to discuss and iterate on the design on this feature. Personally, finding out this caveat with restic mount --allow-other was definitely a surprise to me, so maybe it would make sense to invert this? As in, maybe this PR should be changed so "DefaultPermissions" is set by default, with an optional flag to disable it (that would be a breaking change though)

[codecov-io]

Codecov Report

Merging #2017 into master will decrease coverage by 4.2%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #2017      +/-   ##
==========================================
- Coverage   50.78%   46.57%   -4.21%     
==========================================
  Files         176      176              
  Lines       14165    14174       +9     
==========================================
- Hits         7194     6602     -592     
- Misses       5920     6579     +659     
+ Partials     1051      993      -58

Impacted Files	Coverage Δ
cmd/restic/cmd_mount.go	56.25% <33.33%> (-0.9%)	⬇️
internal/backend/b2/b2.go	0% <0%> (-80.69%)	⬇️
internal/backend/swift/swift.go	0% <0%> (-78.45%)	⬇️
internal/backend/gs/gs.go	0% <0%> (-73.61%)	⬇️
internal/backend/azure/azure.go	0% <0%> (-69.46%)	⬇️
internal/backend/swift/config.go	36.95% <0%> (-54.35%)	⬇️
internal/checker/checker.go	64.54% <0%> (-3.87%)	⬇️
internal/backend/s3/s3.go	60.15% <0%> (-2.26%)	⬇️
internal/cache/file.go	48.67% <0%> (-0.44%)	⬇️
cmd/restic/global.go	28% <0%> (+0.15%)	⬆️
... and 3 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2434ab2...8305114. Read the comment docs.

[fd0]

Hey, thanks for your contribution! I think it'd be good to invert the behavior as you suggested: When --allow-other is enabled, by default enforce permissions and allow to disable this with --no-default-permissions on explicit request. Better safe than sorry, even if this means a breaking change. In my experience, there won't be so many users affected, as using --allow-other is a rather obscure use case.

[kylewlacy]

@fd0 Okay, I inverted the option and rebased!

One thing I wanted to touch on is this change doesn't just affect the --allow-other option. I haven't tested it but I believe this will also break the case where, say, alice owns a repo, bob backs up to alices repo, and alice then mounts the repo (without --allow-other). Previously alice would have been able to see all of bobs files; with this change, she won't have permission by default. Passing --no-default-permissions should fix this case as well though.

Personally, this seems like such a corner case that I doubt it would affect many (if any) cases in the wild, but I figured I'd mention it

[fd0]

I've added a commit which changes the logic slightly: checking the permissions in the fuse mount when nobody else besides the current user can access the fuse mount does not make much sense. The current user has access to the repo files in addition to the password, so they can access all data regardless of what the fuse mount does.

Enabling --allow-root allows the root user to access the files in the fuse mount, for this user no permission checks will be done anyway.

The code now enables DefaultPermissions automatically when --allow-other is set, it can be disabled with --no-default-permissions to restore the old behavior.

That's the best compromise in my opinion, and it only changes the behavior when --allow-other is passed.