2

To allow users to run backintime. I am usually running backintime-kde on ubuntu in the following way:

sudo su
ssh-agent bash
backintime-kde4 --config /root/.config/backintime/config --profile-id 1

This is the only way I found which was working on my system. In particular 

sudo backintime-kde4

and 

kdesudo backintime-kde4

will not work.

I would like to allow ordinary users who do not have permissions to run sudo su to execute backintime as well. Can I somehow create a shell-script from the commands which can be executed by any user such that he has to enter at most his own password (and maybe that of the ssh-key).

Please do not suggest alternate ways of running backintime. I merely search a method equivalent to the one described above (such that backintime operates in the same tested way). However the user should be able to run it without being able to obtain general root privileges.

Germar
  • 6,217
  • 2
  • 24
  • 39
highsciguy
  • 819
  • 2
  • 13
  • 23
  • 1
    There's never any point in running `sudo su`. Just run `su` directly or `sudo -i`. – terdon Jul 20 '14 at 14:34
  • If I run `su` on my system it expects a password which I don't know (not configured?). `sudo -i` would work, but by itself it does not seem to solve the problem. – highsciguy Jul 20 '14 at 15:27
  • 1
    No, that wasn't a solution. That was just me being pedantic, `sudo su` bugs me, there's absolutely no point to it and that's what `sudo -i` is for. Anyway, please [edit] your question and explain how exactly "it doesn't work". Are there any error messages? Why do you need to pass a specific config file to `backintime` and why is that file in root's home directory that only `root` has access to? – terdon Jul 20 '14 at 16:04
  • The ways it doesn't work are plentiful and so are the error messages. Depending on what I try (local or with ssh, user directory or root, backintime or backintime-kde, with ssh-agent or without, ...). The ultimate goal is to backup a specific machine (data from several users directories) automatically to a server via ssh (without asking the user). Therefore the solution to have the configuration in root makes some sense. In summary: I don't want to change the way I do the backup because it is the result of a painful optimization process. The question is if there is a solution which simplifies. – highsciguy Jul 20 '14 at 16:19
  • Please [edit] your question to add extra information, it is hard to read and easy to miss in the comments. Could you explain how it "doesn't work"? Does it not run at all? Does it not backup? Does it backup the wrong stuff? Most importantly, are there any error messages? We need to know how it fails in order to understand the issue. Could you show us the config file? Normal users will never (should never anyway) have access to `/root`, there is no reason to. Why not have a global configuration file that is world readable? – terdon Jul 20 '14 at 16:22
  • One reason why the configuration can't be entirely global is that I don't want to give all users access to the server therefore the private ssh-key should be only root-readable. I don't want to complicate the configuration by restricting rights on the server (can't do it anyway). Also, I think, backintime may store a root-readable password. When I perform the backup as described there are apparently incorrect errors like "Not configured!". The backups finish however gracefully. – highsciguy Jul 20 '14 at 20:37
  • [here is](https://github.com/NixOS/nixpkgs/issues/18012) desription about using textual polkit authorization agent – K.Przybylowicz Oct 21 '22 at 13:32

1 Answers1

3

There seems to be more than one issue:

1. Bug #1276348

ssh-agent is missing in backintime-kde in versions <= 1.0.34. Please install this patch with sudo patch /usr/bin/backintime-kde4 < backintime-kde4.diff

2. sudo vs. kdesudo

sudo doesn't change $HOME but kdesudo does.

$ sudo env | grep ^HOME
HOME=/home/germar
$ kdesudo env | grep ^HOME
HOME=/root

BackInTime need to be started with kdesudo (or gksudo on Gnome). That's also why BIT didn't found your config automatically.

3. Permissions are messed up

You might have messed the permissions.

/home/<USER>/.config/backintime/ and /home/<USER>/.local/share/backintime/ should be owned and writeable only by <USER>

/root/.config/backintime/ and /root/.local/share/backintime/ should be owned and writeable only by root

4. Make various users able to run BackInTime as root

First of all: this is very dangerous and I will NOT recommend doing this!

Your users will have write access to the whole system. They can change every configuration, spy on other users home folders and break the whole system. This will undermine every security concept of Linux.

You should rather configure BackInTime for every single user so they will just backup their own home. This way they don't need root permissions at all and you and I can sleep well again ;-)

If you still want to do so you could create a new group sudo addgroup backintime and add your users as members sudo adduser <USER> backintime. Then add this line to /etc/sudoers

%backintime ALL=NOPASSWD: /usr/bin/backintime-kde4

Log out and log in with <USER> to activate the group membership and you should be able to run kdesudo -c /usr/bin/backintime-kde4 without being asked for a password. But again: DON'T DO THIS

Disclaimer: I'm member of BackInTime Dev-Team

Germar
  • 6,217
  • 2
  • 24
  • 39
  • Thanks! I have version 1.0.34-0.1, so I seem to be affected indeed. The security issue you describe, is it because users with these privileges users may change the configuration within `backintime-kde4` such as to backup the root to their own target and then read the files? Would this be different if I would allow them to run only the command line version `backintime` with specified config file in /root? – highsciguy Jul 23 '14 at 09:13
  • If I would allow password less backup for all users (with ssh-key) this would still imply that they gain access to the server if not I restrict this server-side, right? – highsciguy Jul 23 '14 at 09:19
  • From BackInTime GUI you can open every file for editing. So a user could open `/etc/sudoers` and add him self for passwordless sudo exec for all commands to get full root access to your machine. With some little tricks user could also run every command with root permission directly from BIT. You could add backup users for every single user on your server and create passwordless login for just their own backup user. This way they can only play around with their own stuff. – Germar Jul 23 '14 at 20:27
  • Currently I do not have this option. My ssh server is one with restricted capabilities on an energy saving android device and allows only a single user. – highsciguy Jul 24 '14 at 09:31
  • I had similar problems with commandline `backintime` (actually I had created a bug for it). Is there a patch for it as well? – highsciguy Jul 24 '14 at 15:56
  • Please help me out. Which bug report do you mean? You could also use mode 'SSH encrypted', one passphrase-less login for all and different encryption passwords and destination folder for every user. In this way users could still delete all backup of other users if they are in rage mode but they can't spy on them any more. – Germar Jul 24 '14 at 21:30
  • I do not really find the bug right now, but it exists and I saw that you had already answered with the patch. I applied the patch successfully. Only the question if letting the user run the command line backintime manually with sudo would be save is open for me. But perhaps it is not easy to know this. – highsciguy Aug 13 '14 at 10:37
  • No, it's not save. A user could write some malicious code in his home folder, make it executable and let BIT backup his file. Next he could restore the file with root permissions to a different place. So he could for example replace /bin/bash – Germar Aug 15 '14 at 13:51
  • I understand, but I could use sudo to allow only a specific backintime command which includes the backup option (or write a script which performs this command, make it write protected, and add it to the sudoers configuration). – highsciguy Aug 15 '14 at 17:56
  • Why does your users need to start a new snapshot? It would be lot easier/secure to just schedule that. Sorry, maybe I don't get the point. – Germar Aug 15 '14 at 22:24
  • The reason is that some users may be using the machines to be backed up very irregularly and the backup over network would often be interrupted as the user switches off. In these cases it would be better if the user starts the backup consciously and waits until it is finished. I cannot boot the machines remotely to ensure a regular backup. – highsciguy Aug 17 '14 at 10:26