Sat 12 Jan 2008 04:19:35 AM UTC, comment #5:
more thoughts on this... if i were to try to do a push backup system where all the clients shared a common private key i think what i'd do on the server is have the .ssh/authorized_keys command="foo" invoke a script of my own (you'd probably need a remote-schema change too).
the script on the server would validate the SSH_CLIENT env var contains a client which is supposed to be backed up, and then mkdir /mnt/backups/$IP as necessary and finally exec rdiff-backup --server --restrict-update-only /mnt/backups/$IP.
this way the clients can't trash each other easily (assuming rdiff-backup --restrict-* are actually secure :)
but hey... go ahead and add os.mkdir i guess.
-dean
|
Thu 10 Jan 2008 06:47:00 AM UTC, comment #4:
i'm of very mixed opinion.
if you use a single key restricted to:
rdiff-backup --server --restrict-update-only /mnt/backups/
then any of the boxes which have that key can do whatever they want to any of /mnt/backups/subdirs... i.e. they could erase some other server's backup.
personally i think this is a configuration not worth supporting -- it's not secure.
the only configuration which works is to give a dedicated key to each of the servers pushing a backup.
-dean
|
Sun 06 Jan 2008 02:33:10 AM UTC, comment #2:
I can verify that this is still a problem in 1.1.14. If you use the --restrict-update-only option the first backup will fail. So if you have a server that's set to receive rdiff-backup pushes from clients you currently have to set the server to --restrict for the first backup and then change it to --restrict-update-only for subsequent backups. The ideal behavior would be to treat a first backup as an "update" and allow it to run as it does under --restrict, that is still constrained to the specified directory.
In other words if you have rdiff restricted via ssh key to running as:
rdiff-backup --server --restrict-update-only /mnt/backups/
And the request is to backup to /mnt/backups/newserver then if the directory /mnt/backups/newserver exists then process as happens now. If it doesn't exist then allow the creation of the first backup so long as the directory is still within the one specified by the restrict statement.
|
Tue 20 Jun 2006 09:37:53 PM UTC, original submission:
I created some remote backups and then set up a "secure" enviroment with the help of --restrict and --restrict-update-only. In the directories where the backup was created and then incremented (before I setup this flags) everything works as it should, but (!!) in the directories where there hasn't been an increment (till now) I now (with the restrictions set up) get the following error:
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.error_check_Main(sys.argv[1:])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 295, in error_check_Main
try: Main(arglist)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 315, in Main
take_action(rps)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 271, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 328, in Backup
backup_final_init(rpout)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 432, in backup_final_init
if not inc_base.lstat(): inc_base.mkdir()
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line 863, in mkdir
self.conn.os.mkdir(self.path)
File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line 448, in _call_
return apply(self.connection.reval, (self.name,) + args)
File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line 370, in reval
if isinstance(result, Exception): raise result
rdiff_backup.Security.Violation:
Warning Security Violation!
Bad request for function: os.mkdir
with arguments: ['/target/backup/dir/rdiff-backup-data/increments']
The solution would be to allow os.mkdir to create directories if they are in the rdiff-backup-data subdirectory inside of the restricted path! Or to create ALL subdirectories inside rdiff-backup-data that could be needed at some point in the future when the program is executed at the first backup!
|