If you have multiple disks, some reserved for BackupPC, thenit makes sense to backup the remaining disks to BackupPC.
Even if you haven't installed dedicated disks for BackupPC's data,backing up the non-BackupPC parts of your file systems providesprotection from inadvertently deleted data.
Back to Top
The three issues are:
In some case, although not likely, you might need to set$Conf to 'localhost' if the XferMethod can'tcontact the host by regular host name.
Daniel Poelzleithner suggests the alternative of using sudo, so there isno overhead with ssh. For example:
$Conf = '/usr/bin/sudo $tarPath -c -v -f - -C $shareName+ --totals';
Then run visudo to give BackupPC permission to run sudo without apassword, but only be able to run the /bin/tar command. For example,add this line:
backuppc ALL = NOPASSWD: /bin/tar
Note that an attacker who can become the backuppc user can thenuse sudo to run /bin/tar as root. Importantly, this means they canwrite files anywhere on the file system by doing tar -x. Thisallows them to become root.
If you want to be more cautious, you could create a short shell script(eg: tarCreate) that includes the create argument arguments from$Conf, eg:
#!/bin/sh -f
exec /bin/tar -c $*
Make sure this script and all parent directories have no writepermission. Then remove the -c from $Conf and changethe tar path:
$Conf = '/usr/bin/sudo /path/to/tarCreate -v -f - -C $shareName+ --totals';
Finally, run visudo to change the allowed command to /path/to/tarCreate.
In this case, a compromise of the backuppc user still allows the attackerto run tar -c. But this only allows them read aclearcase/" target="_blank" >ccess to files on theserver, which they already have access to simply by inspecting theBackupPC backup data directories.
A similar setup with sudo can be used for rsync. See the SSH FAQ formore information.
Back to Top