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.

[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.

[Alexander-Shukaev]

What's the final consensus on this topic? Should the main instance run under root user to perform complete system backup? Or would it be enough to just run sudo vorta --create ...? I am also looking for general recommendation to perform continuous self-scheduled system backups.

[adatum]

I am also looking for general recommendation to perform continuous self-scheduled system backups.

Use a different tool. Vorta does not seem intended for this. Maybe see if borgmatic suits your needs: https://projects.torsion.org/witten/borgmatic

[m3nu]

Right. We focus on backups of your user files (documents, workspace, desktop, etc).

If you need to back up a server or headless machine, you're better off with Borgmatic or Borg directly.

[Wikinaut]

#note

Running vorta (or borg) as root – when it was installed via pip and „lives“ in $HOME/.local/bin :

# once: place a symbolic link to `vorta` in a suited path such as `/usr/bin` where root sees it
sudo ln -s $HOME/.local/bin/vorta /usr/bin/vorta

# run with -E to get the correct environment
sudo -E vorta

The same applies when you want to run borg as root (as mentioned by @m3nu above) – when it was installed via pip – mutatis mutandis.

[ThomasWaldmann]

place a symbolic link to vorta in a suited path such as /usr/bin where root sees it

Custom stuff should be rather in /usr/local/bin/, but you need to check whether that is in the PATH.

If you have stuff in $HOME/.local/bin you can of course add that to PATH instead of symlinking elsewhere.

[Wikinaut]

Then (only putting /home/user/.local/bin into path for root), I nevertheless get (as root, when typing borg)

Traceback (most recent call last):
  File "/home/user/.local/bin/borg", line 5, in <module>
    from borg.archiver import main
ModuleNotFoundError: No module named 'borg'

However as sudo-user, I get

sudo -E borg
sudo: borg: Befehl nicht gefunden

So, my two lines do work, but your idea appears not to be the full solution: putting $HOME/.local/bin into the PATH is not enough, you need at least a symlink, okay? I am only referring to work as root. As user, that's fine with $HOME/.local/bin .

[mYnDstrEAm]

I think this is a very important issue and the key advantage of BackInTime over Vorta. There's no good reason why Vorta shouldn't also be able to do backups of root-owned files.

It's a crucial feature which would enable system backup&restore (/ full system backups) which is a critical element of any efficient&robust IT system so I'm really surprised there isn't really any proper (GUI-including) solution for GNU/Linux and that isn't already built into Vorta.

It shouldn't be needed to run Vorta as root to get it working – afaik it would even be bad practice (to run any GUI as root) from a security standpoint (even though that's how BiT implemented it). One could simply add directories to sources and maybe check an option like "Backup root-owned files too". If that option is checked the user would need to enter the root password (only) once, maybe using pkexec, whenever the backup profile config was changed which would then set up/alter the cron job (or however the automatic backups are implemented).

[cocoonkid]

Yes, a vorta systemd unit to run backups as root would be highly appreciated. I only backup my home but there are quite a few docker volumes owned by root because they run android etc.

Vorta is for desktops only is loosing as argument pretty quickly. I noticed that the yay wrapper for pacman also has many cache files owned by root in a normal users homedir.

I hope for a solution one day :)

[jaysonwcs]

I don't get the "Vorta is for desktop" argument. It's obvious that some user files are saved on root folders or are owned by root.
I'd like at least to backup my VM configurations and some other /etc files, and they are all owned by root.

I'm currently using BackInTime only for this, but BackInTime uses Rsync with hardlinks, and because of that I lose space when storing the backup.

I would like to have a GUI to make Borg backups with root permissions, and Vorta is the only one I know so far.

Is there any way to make possible to Vorta run as root and perform the scheduled backups on root owned files?

[m3nu]

This thread already has a few workarounds. If we would support adding a custom Borg path (like sudo borg..., that may solve it too. Until then a one-line shell script would do the same. It will still mess up your cache files, use the wrong SSH keys among other things. So not keen on adding this at all.

[jaysonwcs]

The @palto42 suggestion (using the polkit file to call through pkexec, and adding a desktop file to ~/.config/autostart folder) worked for me. The only problem is that it asks for the root password every time I start the computer (and not only when I open the GUI).

I'm ok with this for now.

[graugelb]

It seems to me that the subject here is closed down, so I do apologize to wake "already" up now:
My Subject:
Vorta/Borg use for LMDE5 backup for a stand alone single user private PC storage to an external USB disk.
Usecase: total disk backup mainly to restore the whole system, but potentially also for single files in case of a desaster.

Statues
I use for many years macrium reflect - also for Linux system like Mint, but is slow - with now total trust as of many perfect experiences with restore.
Now I try as backup Timeshift + Vorta, a combination already mentioned before.

To have one system only:
Is it possible to modify Vorta (what has made me already possible to use Borg) so that a whole disk can be stored with ...clickycklicky onyl...?
Same procedure as for the home files.

I can imagine, that Borg is not interested to put work in a non commercial usecase. So I would accept any answer. But an simple answer. Now I am searching and searching and reading and not much understanding beside maybe...

[real-yfprojects]

I think borg isn't focussed on commercial users at all. Borg can backup a list of folders. So you can pass the mountpoint to borg and it will backup the whole drive. For accessing folders and files that have permissions denying access to the logged in user you will have to run borg as a root user / using sudo.

[Iceman248]

I'm new to this and am struggling to grasp where exactly we stand with using Vorta for backing up files owned as root. I don't need the whole system, just some files from within my /home and /etc, maybe /usr that are owned by root. I did manage to run it with "sudo vorta", but some things are a bit wonky like some have mentioned. I didn't understand the polkit file thing. I only backup locally.

[jaysonwcs]

You save the file that palto42 said on his comment (here #801 (comment)) on /usr/share/polkit-1/actions/. Then, you need just to call Vorta on the terminal (or with Alt+F2 on Gnome) with the following command: pkexec vorta.
It will ask for root password and will open a second instance of Vorta as root user.
If you want to autostart it, you can create a desktop file on the autostart folder of your distribution/desktop environment (on Gnome is /home/your user/.config/autostart/).

On this link (https://gist.github.com/palto42/1064ab6d95240545c56afd9cebd44171) there's the content of a polkit file. You just copy it and create the file on /usr/share/polkit-1/actions/ with the name com.borgbase.Vorta.policy (as sudo). Then, you create the desktop file on /home/your user/.config/autostart/ folder (in case you're using Gnome environments) with the name com.borgbase.Vorta_root.desktop and copy the contents of the second file shown on that link.

It will ask you for root password every time your desktop starts though. It's a small inconvenience, but I'm ok with that because I really prefer Vorta over borgmatic.

If you're using another distro or desktop environment, you'll need to search online where you can create the desktop file, but every environment has its own folder to autostart apps.

[Eeems]

A little bit of a necropost, but if you are using a arch based system, I threw together a AUR package for this: https://aur.archlinux.org/packages/vorta-root

[eliliam]

A little bit of a necropost, but if you are using a arch based system, I threw together a AUR package for this: https://aur.archlinux.org/packages/vorta-root

Do you install this in addition to vorta or does it replace it?

[Eeems]

A little bit of a necropost, but if you are using a arch based system, I threw together a AUR package for this: https://aur.archlinux.org/packages/vorta-root

Do you install this in addition to vorta or does it replace it?

A quick look at the PKGBUILD will answer that question for you: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vorta-root#n16

[Taxicletter]

I have question about what exactly is in /etc. When I searched, it would be configuration files. Aren't configuration files not (also) in the .config folder in the home folder?
What I want to know is: if you DON'T back up /etc, what exactly do I loose? I have a backup in case of a major crash. So I can easily restore a system to keep on working. Are the files in /etc necessary for that? Does it have my e-mail-credentials or wifi-password? Or is there stored if I have a panel on top or at the bottom of my screen?

The problem with the permissions for me, is not the files that are not backed up. The problem is more, that I each time get a "back up with warnings" and then I should look at the logs if it's only those etc-permissions, or if there is a more serious problem. And since I'm no programmer, a lot of what's in the logs is comprehensible for me.

[knezi]

~/.config is for your personal configuration, whereas /etc for system-wide. Well this is hard to generalise, but all your user config should be in your home (e.g. panel on top/bottom, password...).

As for /etc, I can think of wifi passwords (at least for NetworkManager), login manager (e.g. auto login), systemd enabled units... The question is even if you back it up will you be able to restore the files later? Simply copying the entire directory over to the new destination will give conflicts.

I personally, back up my entire / and then only specifically pick directories that I'm missing. Impossible to do if you don't know what they mean.

[linuxturtle]

I just recently started using borg to do remote backups of my homelab, and discovered Vorta, and was pretty excited to have a super slick/easy/fast way for me and my family to backup our desktops/laptops as well, then I ran into this problem... So, to summarize the thread I've read so far (for the convenience of any that come after me):

If you want to backup any files that aren't readable by the user you're running the Vorta GUI as, you should probably choose a different backup GUI/solution (BackInTime was mentioned). There are workarounds in this thread involving various ways to run Vorta or borg as root, but they're all kludges creating various security and convenience issues, and the Vorta maintainer doesn't really think this is a problem worth fixing, or at least doesn't see an easy way to fix it.

Please correct me if that summary isn't accurate.

[linuxturtle]

OK, so after setting up BackInTime on my desktop, I think a followup is in order. It's hardly a panacea either. The way Backintime solves this problem is similar to one of the Vorta workarounds, it has a "run as root" .desktop file for the GUI. This is less of a security problem with Backintime than it would be for Vorta, because Backintime's GUI is only used for setup and recovery, and doesn't need to be running all the time. Note that if you're setting up the schedule, and you're trying to back up a machine that isn't powered on at predictable times (i.e. desktop/laptop), be sure to choose "anacron" as your scheduling method. Otherwise, it's run by root's crontab, and if your machine doesn't happen to be powered on at the scheduled time, that backup will be missed.

[eliliam]

Yeah I'm pretty disappointed in the maintainer's stance on not supporting backing up the actual system, as that's truly what most people need, not just their home folder backed up. I prefer Vorta over BackInTime, but honestly it's a hard requirement to be able to back up all my configs and other non-user owned files, as those hold a lot of very important information for configuring your system.

Edit: Thanks @linuxturtle for the tip about using anacron, I never knew that was an option, very convenient!

[linuxturtle]

Hmm, my original post reads as a bit critical of @m3nu (the Vorta maintainer), and I didn't mean it to be, so maybe an apology is in order from me. I see his reasons for not wanting to fix this, as it's a complicated problem without a tidy solution. Vorta is supposed to be a simple and easy to deploy GUI front-end for borg, but in order to fix this issue, it would have to either be insecure (run as root 24x7, while simultaneously showing up in the unprivileged user's GUI), or get a lot more complicated (probably have some kind of privileged daemon running, which the front-end would connect to). There aren't any simple or neat solutions AFAICT.

@eliliam, humorously, backintime doesn't actually use anacron when you select anacron, it just sets up an "every 15min" cron job in root's crontab to run itself, then it does an anacron-type thing and decides if it'll actually run, or just exit, depending on how long ago it last ran 😆

[m3nu]

No worries. If there is something to improve to make it work better with root, we can always do that. I'm not too experienced with Linux desktops, working on Linux servers mainly and mac desktop.

E.g. we could add a suitable .desktop file to the repo that works with root and document that.

[linuxturtle]

The run-as-root .desktop workaround is easy, and documented well in @palto42's gist, but I'm not sure it's a good idea to put in the repository/packaging for general usage for everyone to run (it's dangerous, and inadvisable to run a GUI app as root 24x7, with the GUI controllable by an unprivileged user, unless you really understand the ramifications of doing so). Backintime does it, but their GUI only runs during setup, and when you need to recover files. Periodic backups are done via a root cron job running a backend non-gui app, and it doesn't depend on the GUI for scheduling or running backups. I don't think there's a clean way to do this without a major rewrite of Vorta, separating frontend/backend, and only running the backend as root when authenticated via sudo. That would be a lot of effort, and I can totally see the POV that it's not worth it to make Vorta work as a full-system backup, when it wasn't conceived that way.

[greenmoss]

TL;DR: I offer another use case for Vorta with full-disk/root access: OS X users who want to back up all of their files, and are tired of fighting with OS X full disk access restrictions. This alone was a big selling point for me to try out Vorta.

More blah-blah from me:

I have been using a custom shell script to run Borg backup for years now.

It's "OK", with caveats:

• My installation of Borg requires Python, which is from homebrew, which periodically updates, thus loses full-disk access, thus invisibly starts breaking my backups
• I had to spend the time to write a shell script
• I had to finagle OS X to run the shell script
• OS X keeps mutating in weird ways that invisibly break my shell script - full disk access, discouraging/hiding cron, etc
• Editing and updating the shell script is fragile

Vorta is so close to what I need! I hope the root access thing can get a nice, elegant solution that fits with the GUI. Great work so far!

If you fine people decide against root access, I'll be sad, and go back to hacking my sad shell script.