Proposal: Mount archives with permissive options again

[Hofer-Julian]

My archives contain folders owned by root. I've noticed that when up-to-date Vorta mounts these archives, these folders are not accessible anymore. The reason is that this commit https://github.com/borgbase/vorta/commit/95d964c40f6bc284cca2ed0d9dd5cff8096fcf34 stops overriding permissions unless a newly created setting key is set.

I propose to revert this change for the following reasons:

• If you want to restore files with the same permissions "extract" instead of "mount" should be used
• It is unclear what the setting does without reading the code

[m3nu]

Maybe we can improve the setting text instead of reverting? There are good reasons for both cases.

[Hofer-Julian]

There are good reasons for both cases.

Were users complaining about the permission override?

One alternative might be the "allow_other" option. https://manpages.ubuntu.com/manpages/bionic/man8/mount.fuse.8.html

[m3nu]

Yes. IIRC those mount options aren't available on every platform/FUSE implementation. So we made it optional.

[m3nu]

How can we solve this? I prefer keeping this an option. Are there 2 options in total? If the text is bad, let's improve the text.

[Hofer-Julian]

How can we solve this? I prefer keeping this an option. Are there 2 options in total? If the text is bad, let's improve the text.

What do you mean with 2 options? The way I see this conversation is that I hoped that we could remove an option, but you remembered cases where it has to remain optional.

If that's the case, then this issue can be closed from my side :)

[m3nu]

Currently we have 2 options:

1. Mount with the same permissions as original files. This works well on the same computer.
2. Override user and permissions. This is needed when restoring on a different machine. E.g. if I want to restore a file from another server. So with option umask=0277,uid={os.getuid()}

We clearly need those two options. My question was if we need a third one. E.g. allow_other (which is only avail on Linux, IIRC).

Also how the text could be improved 'Try to replace existing permissions when mounting an archive.'

[Hofer-Julian]

My question was if we need a third one. E.g. allow_other (which is only avail on Linux, IIRC).

Mmmh, I might misunderstand what exactly allow_others does, but I used it in the past to restore files from another server. So the same use case as we use umask=0277,uid={os.getuid()} for. I don't know if this option is linux only.

Also how the text could be improved 'Try to replace existing permissions when mounting an archive.'

How about: Override permissions when mounting an archive. (Useful when accessing files of a different machine)

[m3nu]

Hmm. alllow_other seems to do something different on macFUSE. This talks about permissions after mounting the volume.

With allow_other, the volume will be accessible normally to all users. 1

For Linux, the situation seems clearer, but the option needs to be enabled explicitely? 2

This option overrides the security measure restricting file access to the user mounting the filesystem.

umask=0277,uid={os.getuid()} doesn't work 100% either. I think I had trouble with ACLs at some point when restoring from a Syno NAS on my desktop. Never found a way to get it working. It does help with normal permissions.

[jucor]

Fixing this would be very helpful, please! I'm on MacOS, and when, on my laptop as my local user with a given UID, I mount an archive created on a multi-user system (my own Syno NAS, where I am root), I cannot CD into the sub-directories that were owned by users with other UID :/ I have checked "Try to replace existing permissions", but there are still directories I can't access: they have the right UID but have permissions 000, which is not ideal. Any idea how to fix this, please?

[m3nu]

There is an option to override some permissions in the Misc tab. This works, if normal perms are used, but not for ACLs in some cases (Synology).

[jucor]

Yes, that's the option I've been using. And indeed, the backup is from a Synology NAS :/

[real-yfprojects]

With allow_other, the volume will be accessible normally to all users. 1

For Linux, the situation seems clearer, but the option needs to be enabled explicitely? 2

This option overrides the security measure restricting file access to the user mounting the filesystem.

As I understand those quotes, the options works the same on both platforms.

[m3nu]

Syno is a special case. They have standard perms all set to deny and only use ACLs.

[jucor]

Damn. Fuse doesn't seem to have ways to override ACLs. Any idea how, even with extra commands user-side or root-side, I can access those files, please?

On Mon, Jun 27, 2022 at 6:01 PM Manu @.***> wrote:

Syno is a special case. They have standard perms all set to deny and only use ACLs.

— Reply to this email directly, view it on GitHub https://github.com/borgbase/vorta/issues/1029#issuecomment-1167342909, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFBERMKITW5T73ZHY5ATQTVRHM53ANCNFSM5AFDDYZA . You are receiving this because you commented.Message ID: @.***>

-- Julien Cornebise, Ph.D. (he/him) Honorary Associate Professor Department of Computer Science University College London https://cornebise.com/julien

[Hofer-Julian]

Why not use extract instead of mount?

Afterwards you can change permissions locally.

[jucor]

Remote, big archives: painful to download when all I want is browse for a few checks - and actually impossible to extract my while NAS archive on my laptop's small SSD :)

On Tue, 28 Jun 2022, 15:21 Hofer-Julian, @.***> wrote:

Why not use extract instead of mount?

Afterwards you can change permissions locally.

— Reply to this email directly, view it on GitHub https://github.com/borgbase/vorta/issues/1029#issuecomment-1168790435, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFBERKNY6HDR37BUUKUE2TVRMC5BANCNFSM5AFDDYZA . You are receiving this because you commented.Message ID: @.***>

[m3nu]

You can filter or view to pull a single file. Borgmatic even lets you search for a filename.

Else you need a Linux machine, because the ACL stuff won't work on macOS at all.

[edakimling]

I would like to add my 2 cents. I have a highly organized structure in my home folder. It contains 'higher level' folders owned by root on purpose, so I do not erase them by mistake and notice it much much later. Only 'low level' folders and files have write permission by me.

This works fantastic. Now I am trying to restore this using rsync to another drive from a vorta mounted volume. I mounted the volume in vorta and of course could not even dir into those folders as a regular user, because they are owned by root. Thus, I need to run vorta as root. If I do that, then I can't even access the archives to begin with. It's a catch 22.

I am not super skilled with linux. I can hold my own, but it takes me time. It took me forever to figure out that this was because vorta uses borg, who then uses fuse.mount and vorta passes arguments to mount as local user. I only figured this out after many tries at searches on the internet, because I did not even know what to look for as an issue. Finally searching here in the issues clued me in.

I know there is hesitancy of the vorta devs to deal with this. But cases were presented where this is a legitimate use case scenario. We cannot always use extract due to space constraints and expecting every single directory in /home folder is owned by the user is also not realistic to be the case 100% of the time.

User @Hofer-Julian was dead on. allow_other totally works. I went through the logs and copied the borg mount command vorta issues. And then I added -o allow_other. And voila, the fuse mount point was mounted allowing the root access and all my issues are resolved.

I have read through this post and it seems the hesitancy to incorporate this is because it is not consistently implemented across other OSes, namely macOS.

But there is a super simple solution. In 'schedule' pane, you already have a field for extra borg parameters to pass along to borg create. Why not then, make another such textbox field on the 'misc' pane for borg mount. Perhaps even put a info text there that commands for fuse.mount can be put there and if one needs to have access to root folders within the backup, to consider passing allow_other.

This way, you are not compromising anything. There needs not be a discussion if this exposes some security issue, because borg already supports this.

In the meantime I will run a command line borg mount -o allow_others to open my archive. But it would be so nice if I did not have to drop to the CLI to do this one command and use vorta for everything else...

Thanks!

[real-yfprojects]

Why not then, make another such textbox field on the 'misc' pane for borg mount.

Good idea. However adding entries for every borg command would clutter the GUI too much in my opinion. That's why I hope #379 will be able to allow such a thing by making vorta more hackable.

[jucor]

A UX trick to keep the GUI uncluttered: hiding some of those extra features behind an "Advanced" button, or a flags page? This way the main UI stays uncluttered and slick, yet powerusers can find what they need too.

[edakimling]

Totally agree with @jucor; hiding 'complexities of UI' behind an 'advanced' button has been an elegant solution for many UI.

I do not think @real-yfprojects that we are trying to introduce 'every borg command'. And this issue is rather significant, and it affects core functionality of vorta. The fix is really really simple.

I text box to pass to borg create command params, hidden behind an 'advance' button to show all such advance features, would I think satisfy everyone: it's elegant, it's simple to add as feature, it breaks nothing, and it brings vorta closer to what it claims on its website, that you can back up anything.