Run Backup Task with Root Permission

[Wikinaut]

I usually run Vorta as a user. However for a complete backup of e.g. the /etc files, I think, it will be necessary to run Vorta as root.

My wish and suggestion is that you describe the best way to perform such backups in your description or readme.

[Wikinaut]

For example, will a mere running as

sudo /home/user/.local/bin/vorta

be sufficient to be able to backup all files including the files belonging to root?

[luckyrat]

I'd also appreciate some further guidance or links to relevant external documentation.

Ultimately I would like to see and use Vorta in the (non-root) user Gnome system tray (Ubuntu 18.04) with auto-start on system start (or at least Gnome login) and have the backups Vorta schedules ran with root permissions so that a full system backup can be taken.

To start with, I tried to just get it to run manually from a terminal window running in Gnome and failed:

<prompt>:~$ sudo vorta
sudo: vorta: command not found
<prompt>:~$ whereis vorta
vorta: /home/<user>/.local/bin/vorta
<prompt>:~$ sudo /home/<user>/.local/bin/vorta
Forking to background (see system tray).
<prompt>:~$ QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

At this point Vorta did not appear to be running but it may have been only the system tray part of it that was broken. I killed the background process and just ran as a normal user, which at least allows me to backup some files until I get this figured out...

<prompt>:~$ ps -ef | grep vorta
root      9612  4758  1 10:37 pts/0    00:00:00 /usr/bin/python3 /home/<user>/.local/bin/vorta
<user>  9641  8483  0 10:38 pts/0    00:00:00 grep --color=auto vorta
<prompt>:~$ sudo kill 9612
<prompt>:~$ vorta
Forking to background (see system tray).
<prompt>:~$ 

[ThomasWaldmann]

Just as an idea, did not test that yet:

if one uses the fat-binary of borg, it could be owned by root:root and be suid. Then vorta could run as normal user and borg would run as root.

This does NOT work with scripts though (e.g. shell or python), only with binaries.

[m3nu]

Not a fan of such workarounds. With Borg being suid, an attacker could change any file on the machine. (via borg extract)

Personally I'd either put your own user in some kind of "admin group" that has access to /etc or back up system files with Borgmatic running as root. The use case for Vorta is mostly to back up your personal files and home folder.

[luckyrat]

I guess that statements on the front page like "One place to view all point-in-time archives and restore individual files." gave me a different impression of what Vorta is for.

Maybe it's just me that interprets this as it being a complete backup solution for a system but if it is only supposed to be used for some files that's fine, I'll look into what this Borgmatic alternative is instead. Thanks for the advice.

[m3nu]

Vorta is for desktops environments, not servers. Your use case belongs more to the server space. There, a headless solution, like Borgmatic or a shell script will work better with regards to permissions.

If you're motivated you can surely run the backup task with sudo/suid and have full system access. It's just not a scenario we will support.

You can still use Vorta to access and restore those backup repos. I just don't recommend circumventing your local permissions and giving a user application deep system access without knowing your exact situation.

[Wikinaut]

@m3nu wrote

Vorta is for desktops environments, not servers.

Äh, well, but.... for example some /etc files are still as important as user files. And databases.

So I think, as discussed above, at least the preferred-by-the-maintainers view should be explained. If you - for understandable reasons - do not suggest/recommend Vorta for these purposes, this should be mentioned.

[luckyrat]

Vorta is for desktops environments, not servers. Your use case belongs more to the server space.

Fair enough. For context, I'm approaching the Linux backup in the same way as I have always backed up my Windows desktop environment (using tools that take regular differential backups of the entire system to enable both a quick bare-metal restore and fine-grained protection against short-term user file corruption/ransomware/human error). Given how hard I've found it to identify reliable software to achieve this I can entirely believe that it's just not a backup strategy that fits Linux as well as Windows and I will most likely learn more about better strategies as I read about Borgmatic.

I like what I've seen of Vorta so far and may well keep using it as part of a more complete backup solution.

[m3nu]

If you guys are really keen on doing backups as root, then I suggest to just run the borg command with sudo. So borg create ... becomes sudo borg create. Should be simple enough to configure passwordless sudo for just the Borg-command?

The PR for this should be quite simple. This option could be enabled under Misc or as env variable.

Would this solve your use case?

[luckyrat]

Should be simple enough to configure passwordless sudo for just the Borg-command?

That's not something I've done before (sudo has always involved me typing a password).

I guess that this approach would still open up the risk of an attacker using sudo borg extract to overwrite arbitrary system files?

I think from a security perspective, the sort of solution I was dreaming of would involve a secure way (requesting root/sudo password for example) of configuring a script to run as root such that it can do a full backup of the system, with the scheduling and monitoring available via Vorta but without the ability for a user-account compromise to allow arbitrary root file access. The more I think about, the more it sounds like a fantasy world and I would think all similar systems I've used on Windows would have suffered from this same risk.

[Hofer-Julian]

I think from a security perspective, the sort of solution I was dreaming of would involve a secure way (requesting root/sudo password for example) of configuring a script to run as root such that it can do a full backup of the system, with the scheduling and monitoring available via Vorta but without the ability for a user-account compromise to allow arbitrary root file access. The more I think about, the more it sounds like a fantasy world and I would think all similar systems I've used on Windows would have suffered from this same risk.

You can currently do that with a combination of Timeshift and vorta. I never used timeshift myself, but it is quite popular, several distros include it by default.

I don't know if it is feasible, to do something similar in vorta.

[m3nu]

I guess that this approach would still open up the risk of an attacker using sudo borg extract to overwrite arbitrary system files?

No. The passwordless sudo can be restricted to specific commands. So only borg create runs without password, but borg extract doesn't.

Only borg create would run with sudo. All other commands don't need it. (except for borg check maybe)

[Wikinaut]

(just let me drop it: thank you all - apart from working for/on borgbackup - for the - honestly - fruitful discussion of this topic.)

[ThomasWaldmann]

Well, "it depends".

locally-mounted-filesystem repo

once you start doing "sudo borg create", your repo files will be owned by root and also your borg cache might be in /root and be owned by root (depends on sudo options). if you then use borg as non-root, you'll run into permission issues when accessing the repo files and either the same for the cache files or you'll have 2 different caches, one for root and one for the non-priv. user (might be a space and time consumption issue).

ssh: repo

files in a ssh: remote repo are owned by the ssh login user, so no problem here.

one can use someuser@localhost to access local filesystem files and avoid the permission issues.

borg extract

If one uses root to archive files not owned by the non-privileged user, one of course also needs root to correctly restore them (including file ownership and maybe also some other metadata). If you are a non-privileged user, you can't chown stuff away from yourself.

[m3nu]

Valid issues, @ThomasWaldmann . Didn't think of the cache and permissions.

The ssh-workaround mentioned already has its own issue #53. The generalized version would be "Set custom borg command", which could be sudo borg or ssh root@localhost borg.

To make this work, the user needs to set up SSH keys on their local machine and be very disciplined with any command he runs. I'm fine with adding this for power-users who need it in special cases and know what they are doing.

[adatum]

If Vorta cannot, and is not intended to, backup system files and other users' files, I think this should be mentioned in the website and documentation.

I was considering using Vorta, but my goal is to create a complete system backup of a desktop and laptop. Based on this discussion, perhaps Vorta is not the right tool for the task.

[leggiero]

Hi guys. I'm a new Vorta user and arrived in this thread as had the same issue of not being able to backup some paths that needs super user permission. Please, consider allowing custom borg commands where we can specify sudo, or just add the option to run as sudo only the borg create command called by Vorta. Unfortunately, I'm temporarly using a command line based solution, but I'm waiting for this feature to use Vorta again. Will be following this thread. Also, if you need beta testers, I'm here :-)

[poleguy]

I am working on a complete restore solution for a combined desktop/server use case. I don't like to focus on backup, because that's not the valuable part. :-)

I am trying out borgmatic as recommended in this thread, because I noticed vorta "silently failed" to back up some of my files because it's not running as root, and gives no visible warning if there are permission errors in the log. You have to click the logs and read through them to know there is trouble.

However, I like vorta particularly for the gui restore...borgmatic, not so much.

I don't distinguish much between 'server' and 'desktop' machines. I run 'server' processes on my desktop much like a server, and like many users I want backups of /etc so restoring my machine to working order is not a tremendous nightmare when something goes wrong. I'd also like to back up data that might belong to other user accounts (e.g. minecraft server account data, other user accounts, scripts sitting in root home directory, etc.).

Even if I do use borgmatic, I'd want a way to easily restore, so vorta is nice for that. Researching how to restore via command line is maybe not fun when you are under the stress of something bad having just happened.

Seeing the gui icon is also a nice way to remember that backups are running and borgmatic doesn't do this.

So if I'm going to use vorta for restore, I'd like to use vorta for restoring borgmatic as well. But maybe I'm wrong. I'm not sure on the solution to this yet.

I don't think an admin group is enough if you need more than just /etc. Also I think that backup and restore should be at the same security level. Otherwise I think you are putting a hole in security: sudo borg create followed by borg restore might let a (compromised) user account read files they don't otherwise have access to. I think it's safer to keep it all as root or all as user to promote clear security thinking.

It would be nice to have a discussion of the use case intent in the getting started page, and a recommendation how to back up other user accounts, /etc, databases, and other data, so that vorta plays nice in this use case.

Also a screen shot showing how to check the log after your initial backup to check for permission trouble... and maybe an automatic warning?:

https://vorta.borgbase.com/usage/local/

If I find a nice approach, I can write it up. For now I'm thinking vorta directly for my main account, borgmatic as root for /etc, other users, databases, and run vorta as root for restore of the borgmatic stuff as needed. I'm open to ideas. Has anyone worked this out?

[witten]

Late to the party here. If I can make any changes to the way that borgmatic creates archives to improve the ability of Vorta to restore them, please let me know. I'm happy to look into that. However I imagine restoring with Vorta doesn't solve the root/non-root thing—you'd still need a way to restore privileged files. One of the work-arounds mentioned above may help with that.

[m3nu]

I am trying out borgmatic as recommended in this thread, because I noticed vorta "silently failed" to back up some of my files because it's not running as root, and gives no visible warning if there are permission errors in the log. You have to click the logs and read through them to know there is trouble.

We regard backup runs as complete, even if some files were unaccessible, because it's very very common. E.g. on macOS many folders, like calendar or contacts storage are not accessible by default.

We could still add note in the docs or show a note in Vorta. Though this may be confusing.

[amarendra]

on macOS many folders, like calendar or contacts storage are not accessible by default

Indeed.

While restic reads them and backs up just fine I have not been able to do it via borg (I run it from a script). I gave both borg (both original location - installed via Homebrew and symlinked path) and my script full disk access but it still can't read those paths.

[ThomasWaldmann]

@amarendra borg does nothing special, just open/read/close. If it can't do that, it does not have sufficient permissions. You can confirm that by running it as root.

[amarendra]

@ThomasWaldmann I will try it. Thanks.

Yes, it indeed seems to have permission issues.

\~/Library/Mail: scandir: [Errno 1] Operation not permitted: '\~/Library/Mail'

Fails similarly for anything inside ~/Library.

I was just wondering that I installed borg as the user that owns that folder, I am logged in as that user, I have given borg full disk access in settings then what is that I am missing?

[ThomasWaldmann]

I don't use macOS myself, so I can't help you with debugging that.

[witten]

These instructions for running with full disk access on macOS are for borgmatic, but the same general approach may work for directly running Borg as well.

[amarendra]

Thanks @witten. It didn't work for me. Besides I had just set that up for testing - this would have been quite a long-winded fix that would have needed to be kept updated all the time with increased dependencies. I will just skip those folders and find out some other way to backup those ~/Library folders, or add them to my Restic backup and/or Tarsnap backup. Or wait for Vorta to become more stable (assuming that can do it).

[m3nu]

@amarendra, this is neither a Vorta nor a Borg issue. It's a security feature of macOS. If you enable "Full Disk Access" for the said app, you can copy any file, if not, some folders remain restricted. Often those (IMAP- or CalDAV-synced) folders shouldn't be backed up anyways. You may have picked the wrong app to allow depending on the way you installed Vorta. To be sure I tested it once again and everything works as expected:

https://files.qmax.us/vorta/vorta-full-disk-access-web.mp4

[amarendra]

Yes right, that's a Mac feature. When I mentioned waiting for Vorta to become "more stable" I was not pointing to this issue at all. I apologise if it came across that way. In fact I assumed Vorta could this do this. The above mentioned borgmatic workaround tries to do the it by bundling the script as an app and since Vorta is an app bundle (I mean I can see .app so again I assume) I thought it could do that.

Often those (IMAP- or CalDAV-synced) folders shouldn't be backed up anyways

But why is that? e.g. I see my messages are in plain text in ~/Library/Messages/Archive and I think it would be good to back keep a backup. That's how I did it till it broke after OS upgrade.

https://files.qmax.us/vorta/vorta-full-disk-access-web.mp4

Thak you :) This is exactly how Tarsnap was able to back it up just now. I anyway plan to try Vorta again this weekend so I will do this.

[samuel-w]

For Linux, we can use pkexec to obtain root permissions for GUI. What is the equivalent for macOS if we need root?

Edit: Actually, root isn't needed for full disk access on macOS. Didn't fully read the comments.

[palto42]

@samuel-w The solution with pkexecworks in principle, I tried it on Solus with polkit file and extra .desktop file.

One observation I made is that it would be useful if the tray icon and the tray menu would change to indicate that this instance of Vorta runs as root. Otherwise it could be confusing and the user may forget that he started it as root.

One caveat I found when running Vorta as root is that it can't open web URLs in a browser, but for me this is no real issue.

[samuel-w]

Currently working on a solution that runs only the create as root. Its a lot more complex because enviroment variables don't transfer over and I have to fix the permissions after.

[palto42]

@samuel-w, not sure I understand the use case of restricting root to borg create. This would allow to create new backups, but not the restore anything from the backup or prune old archives etc.

[samuel-w]

Its possible if you create the backup as root and then fix the permissions with chown

[samuel-w]

I want to reduce the scope of root usage as much as possible to reduce security issues.

[palto42]

Although I understand the security concept of restricting root access to the minimum required, it doesn't very useful to me for this application to restrict it to only borg create which then requires some follow-up actions via root/sudo (e.g. changing permissions) to get things working. But maybe it will get more clear as the development progresses, I'll be patient and wait...

[palto42]

@samuel-w I think we have 2 different use cases for running Vorta as root in mind.

1. Run Vorta as root in background (daemon) to automatically run system backups
2. Run Vorta as root interactively to configure system backups, browse the archive or restore data

I was thinking about 2nd use case, because I currently do my system backups via Borgmatic and mainly looked for a nice GUI to browse the archive. But the first use case looks interesting to use Vorta for unattended non-GUI backups of the whole system.