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


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.

  • 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

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
$ kdesudo env | grep ^HOME

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

  • 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 9: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 9: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 9: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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.