rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] "warning security violation" on fs_abilities.re


From: Andrew Ferguson
Subject: Re: [rdiff-backup-users] "warning security violation" on fs_abilities.restore_set_globals when trying to restore [ctd]
Date: Fri, 25 Jul 2008 09:34:06 -0400

On Jul 25, 2008, at 8:02 AM, Klaas Gadeyne wrote:

Hi,

it seems like I have the same problem as described previously on this mailinglist <http://www.mail-archive.com/address@hidden/msg02352.html >

To be short: - backups work fine
- restores don't

sh-3.1$ rdiff-backup -v7 --restore-as-of now test-backup pc00136- backup::/tmp/testrestore
Using rdiff-backup version 1.1.15
Using mirror root directory /var/backups/test-backup
Executing ssh -C pc00136-backup rdiff-backup --server
Registering connection 1
Sending back exception
Warning Security Violation!
Bad request for function: fs_abilities.restore_set_globals
with arguments: [<rdiff_backup.rpath.RPath instance at 0xb79201ac>]
[snip rest of python stuff that I don't understand]

I'm trying this on 2 Debian stable systems (using the debian packages, that is). I tried with *both* the official stable package and the one in backports, so the issue seems to be unrelated to rdiff version 1.1.5.

sh-3.1$ ls -l /var/cache/apt/archives/rdiff-backup_1.1.*
-rw-r--r-- 1 root root 186224 2008-03-20 09:32 /var/cache/apt/ archives/rdiff-backup_1.1.15-2~bpo40+1_amd64.deb -rw-r--r-- 1 root root 175064 2006-12-27 23:02 /var/cache/apt/ archives/rdiff-backup_1.1.5-4_amd64.deb

Unfortunately, it seems that no solution was provided (at least not *on* list [*]). Any suggestions to further debug this issue?


Hi,

That issue was never resolved for two reasons: I cannot reproduce this problem and the original poster never returned my last (off list) message.

For the original poster, it became apparent that the restore could work the other way -- that is, by logging on to 'pc00136-backup', the user could do 'rdiff-backup -r now backup-host::/test-backup /tmp/ testrestore'.

I have again, just now, tested restoring to a remote host (like you want to do) and it went fine using the latest rdiff-backup. Personally, I suspect that there is some sort of misconfiguration (at your end, or Debian's) due to the multiple versions of rdiff-backup, paths, etc.

To start debugging this issue yourself, you will need to:

1) Make sure there is only one copy of the rdiff-backup files on your remote system. These files live inside the Python site-packages directory. A simple `locate librsync.py` should point you in the right direction.

2) Check the follow lines inside rdiff-backup's files. If you want, you can simply send me the files as attachments and I will check them. - In rdiff_backup/Security.py, there should be a line which has "fs_abilities.restore_set_globals" as part of an 'if sec_level == "all": ' test. - In rdiff_backup/Globals.py, there should be a line which has 'security_level = "all"'


Lastly, if indeed those are the only copies of Security.py and Globals.py on your system, and those lines are set as I indicated, then you should run rdiff-backup with "-v9" (not "-v7") to get the highest level of debugging. Then, e-mail the *complete* output to the mailing list. Please do not snip any part of the debug messages. Although you may not understand the Python stuff, folks on this mailing list do. :-)



Andrew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]