Yaakov, The instructions I gave you below do not require the script that you mention.
Here's an overview of what's going on. In order to back up a host, you need to provide read access to the files you intend to back up. One way of doing this is with 'sudo'. This gives temporary root permissions to a regular user. Why not just connect as root? Well you could, but there is a security issue in doing this. Your BackupPC machine would need to be set up with a no-passphrase ssh key. If someone were log into your BackupPC machine as the backuppc user, that person would have root access to your host machine (the machine you intend to back up). So instead it's suggested you use 'sudo' to give temporary root permission for certain commands only. One way to do that is to write a script 'myscript.sh' and enable the backup user to execute it with root privileges using 'sudo'. The contents of 'myscript.sh' are described in the documentation that you cited. Another way to do it (the way I do it) is to not bother with the script and put the "approved" rsync command directly in the /etc/sudoers file. That is what I described below. Note that you can secure the system even more by omitting the '*' and replacing it with the full list of options and paths that your BackupPC configuration requires. (For instance, if you're only backing up /home, then you don't need to allow 'sudo' ability to rsync /etc, which may contain sensitive passwords. The example I gave below does not make this distinction.) -Rob Yaakov Chaikin wrote: > Also, the script that the documentation suggest one write to avoid an > attacker using rsync to write files on the client machine... Is this > something that needs to be put on the server or the client and who > should have access to that script? > > Thanks, > Yaakov. > > On 7/18/07, Rob Owens <[EMAIL PROTECTED]> wrote: >> according to this link: >> http://backuppc.sourceforge.net/faq/ssh.html#how_can_client_access_as_root_be_avoided >> >> >> the /etc/sudoers line should have looked like this: >> user_with_sudo_rights ALL=NOPASSWD: /usr/bin/rsync --server --sender * >> >> -Rob >> >> >> Yaakov Chaikin wrote: >> > Which of the config directive needs to change for the "sudo" part and >> > how would it look? Could you give an example? >> > >> > Thanks, >> > Yaakov. >> > >> > On 7/18/07, Rob Owens <[EMAIL PROTECTED]> wrote: >> >> If you're going to connect to the host as root, then no changes to >> >> config.pl are needed. If you're going to connect to the host as a >> >> regular user, and use sudo, then config.pl needs to change. You >> need to >> >> replace "root" with the username you want to connect with. And >> you need >> >> to throw a "sudo" in front of the rsync command. >> >> >> >> -Rob >> >> >> >> Yaakov Chaikin wrote: >> >> > Would this require a different configuration within the config.pl >> >> > file(s) within BackupPC itself? Or as far as BackupPC is >> concerned the >> >> > configuration can stay the same as if it has exchanged the rsa keys >> >> > with the user 'root'? >> >> > >> >> > Thanks, >> >> > Yaakov. >> >> > >> >> > On 7/13/07, Rob Owens <[EMAIL PROTECTED]> wrote: >> >> >> Keith Edmunds wrote: >> >> >> > On Fri, 13 Jul 2007 09:39:15 -0400, [EMAIL PROTECTED] >> said: >> >> >> > >> >> >> > >> >> >> >> The user would need read-access to everything (in order to >> backup >> >> >> /home >> >> >> >> and some files in /etc), preferably without being able to run >> >> >> commands >> >> >> >> other than rsync. How would I achieve this? >> >> >> >> >> >> >> > >> >> >> > By using sudo (as I said). Sudo runs the program specified with >> >> root >> >> >> > privileges - we backup lots of servers this way. >> >> >> > >> >> >> > Keith >> >> >> I'm familiar with sudo. I guess I'd specify in /etc/sudoers that >> >> user >> >> >> "joe" is allowed to run: >> >> >> 1) rsync <options> /share1 >> >> >> and >> >> >> 2) rsync <options> /share2 >> >> >> >> >> >> Is there a way to use the forced-commands feature of ssh to >> further >> >> >> limit joe's logins? I realize >> >> >> that the risk is already significantly reduced since joe is just a >> >> >> regular user, but I'm really picky about security. >> >> >> >> >> >> Here's a funny story I heard that I think applies here: >> >> >> Two guys (Fred and Bill) were walking through the jungle when they >> >> >> noticed a cheetah stalking them. Fred bends down to tighten the >> >> >> shoelaces on his running shoes. Bill says, "What are you >> doing? You >> >> >> can't outrun a cheetah." Fred says, "I don't have to outrun the >> >> >> cheetah, I just have to outrun you." >> >> >> >> >> >> I'm just trying to take my security one step further than most >> people >> >> >> would. Hopefully it'll keep me safer than the guys behind me. >> >> >> >> >> >> -Rob >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------- >> >> >> >> >> >> >> >> >> This SF.net email is sponsored by DB2 Express >> >> >> Download DB2 Express C - the FREE version of DB2 express and take >> >> >> control of your XML. No limits. Just data. Click to get it now. >> >> >> http://sourceforge.net/powerbar/db2/ >> >> >> _______________________________________________ >> >> >> BackupPC-users mailing list >> >> >> [email protected] >> >> >> https://lists.sourceforge.net/lists/listinfo/backuppc-users >> >> >> http://backuppc.sourceforge.net/ >> >> >> >> >> >> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ BackupPC-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
