Backup Central

Trying to restore from an rdiff-backup created by root as my normal user, I got
this stack trace:

$ rdiff-backup -r now
/var/rdiff-backups/orca1.orcaware.com/home/blair/Packages/ubuntu/5.10/postgresql-8.0
ppp Traceback (most recent call last):
File "/usr/bin/X11/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line 303, in Main
take_action(rps)
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line 282, in
take_action
elif action == "restore-as-of": Restore(rps[0], rps[1], 1)
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line 462, in
Restore
dest_rp.conn.fs_abilities.restore_set_globals(dest_rp)
File "/usr/lib/python2.4/site-packages/rdiff_backup/fs_abilities.py", line
619, in restore_set_globals
src_fsa = Globals.rbdir.conn.fs_abilities.get_readonly_fsa(
File "/usr/lib/python2.4/site-packages/rdiff_backup/fs_abilities.py", line
405, in get_readonly_fsa
return FSAbilities(desc_string).init_readonly(rp)
File "/usr/lib/python2.4/site-packages/rdiff_backup/fs_abilities.py", line
115, in init_readonly
self.set_resource_fork_readonly(rp)
File "/usr/lib/python2.4/site-packages/rdiff_backup/fs_abilities.py", line
372, in set_resource_fork_readonly
for rp in selection.Select(dir_rp).set_iter():
File "/usr/lib/python2.4/site-packages/rdiff_backup/selection.py", line 132,
in Iterate_fast
try: rpath, val = diryield_stack[-1].next()
File "/usr/lib/python2.4/site-packages/rdiff_backup/selection.py", line 118,
in diryield
for filename in self.listdir(rpath):
File "/usr/lib/python2.4/site-packages/rdiff_backup/selection.py", line 180,
in listdir
dir_listing = robust.check_common_error(error_handler, dir_rp.listdir)
File "/usr/lib/python2.4/site-packages/rdiff_backup/robust.py", line 39, in
check_common_error
if error_handler: return error_handler(exc, *args)
File "/usr/lib/python2.4/site-packages/rdiff_backup/selection.py", line 178,
in error_handler
log.ErrorLog.write_if_open("ListError", dir_rp, exc)
File "/usr/lib/python2.4/site-packages/rdiff_backup/log.py", line 251, in
write_if_open
return Globals.backup_writer.log.ErrorLog.write_if_open(
AttributeError: 'NoneType' object has no attribute 'log'


It wasn't until I used -v 9 that I got this:


Mon Nov 7 21:18:17 2005 Using mirror root directory
/var/rdiff-backups/orca1.orcaware.com
Mon Nov 7 21:18:17 2005 ACLs not supported by filesystem at
/var/rdiff-backups/orca1.orcaware.com/rdiff-backup-data
Mon Nov 7 21:18:17 2005 Exception '[Errno 13] Permission denied:
'/var/rdiff-backups/orca1.orcaware.com/rdiff-backup-data'' raised of class
'exceptions.OSError':
File "/usr/lib/python2.4/site-packages/rdiff_backup/robust.py", line 32, in
check_common_error
try: return function(*args)
File "/usr/lib/python2.4/site-packages/rdiff_backup/rpath.py", line 840, in
listdir
return self.conn.os.listdir(self.path)


Is there a bug here in the logging code? Without the -v 9, I didn't get any
message that something was wrong.

Regards,
Blair

--
Blair Zajac, Ph.D.
<blair < at > orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/

On Tuesday 08 November 2005 07:19, Blair Zajac wrote:
Trying to restore from an rdiff-backup created by root as my normal
user, I got this stack trace:

That's not supported and there are no plans to enable support. Search
the archives for this Subject:

Write-once read-many problem

You'll also find a patch against 0.12.8 that'll give you an indication
of how to hack around the design issue.

Perhaps a few more wishlist requests might encourage Ben to take a look
at adding an option to drop the self.perm_changer() calls for non-root
users.

Ciao,
Sheldon.

Blair Zajac <blair < at > orcaware.com>
wrote the following on Mon, 07 Nov 2005 21:19:13 -0800
Trying to restore from an rdiff-backup created by root as my normal
user, I got this stack trace:
...
Is there a bug here in the logging code? Without the -v 9, I didn't
get any message that something was wrong.

Yes, I think there is a bug in the error code, I will look at it. But
Sheldon Hearn is right, there is an issue with the setup you are
attempting (but I wouldn't call it a "bug" exactly). The problem is
that there are probably some files in the repository that you have
insufficient permissions to read as the non-root user.


--
Ben Escoto

Ben Escoto <ben < at > emerose.org>
wrote the following on Fri, 11 Nov 2005 23:30:52 -0600

Yes, I think there is a bug in the error code, I will look at it.

http://savannah.nongnu.org/cgi-bin/viewcvs/rdiff-backup/rdiff-backup/rdiff_backup/log.py.diff?r2=1.19.2.1&r1=1.19&diff_format=u


--
Ben Escoto

Ben Escoto wrote:
Blair Zajac <blair < at > orcaware.com>
wrote the following on Mon, 07 Nov 2005 21:19:13 -0800

Trying to restore from an rdiff-backup created by root as my normal
user, I got this stack trace:

...

Is there a bug here in the logging code? Without the -v 9, I didn't
get any message that something was wrong.


Yes, I think there is a bug in the error code, I will look at it. But
Sheldon Hearn is right, there is an issue with the setup you are
attempting (but I wouldn't call it a "bug" exactly). The problem is
that there are probably some files in the repository that you have
insufficient permissions to read as the non-root user.

Yes, it appears that the problem is that rdiff-backup's data directory is 700,
which prevents normal users from reading it.

I'm guessing that this is this intended? I would be nice for it to be 755 by
default, to allow non-root users restore backups themselves.

However, from a security point of view, what kind of data are they getting
access to that they should not have? The actual backup files and directories
have the same permissions as the original, so there's no gained visibility. Is
it just potentially a list of the files that were backed up? Could the
incremental data have the file permissions as the original?

Regards,
Blair

--
Blair Zajac, Ph.D.
<blair < at > orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/

Ben Escoto wrote:
Blair Zajac <blair < at > orcaware.com>
wrote the following on Mon, 07 Nov 2005 21:19:13 -0800

Trying to restore from an rdiff-backup created by root as my normal
user, I got this stack trace:

...

Is there a bug here in the logging code? Without the -v 9, I didn't
get any message that something was wrong.


Yes, I think there is a bug in the error code, I will look at it. But
Sheldon Hearn is right, there is an issue with the setup you are
attempting (but I wouldn't call it a "bug" exactly). The problem is
that there are probably some files in the repository that you have
insufficient permissions to read as the non-root user.

And the patch you gave also worked.

Thanks!

Blair

Blair Zajac <blair < at > orcaware.com>
wrote the following on Sat, 12 Nov 2005 19:41:10 -0800

Yes, it appears that the problem is that rdiff-backup's data
directory is 700, which prevents normal users from reading it.

I'm guessing that this is this intended? I would be nice for it to
be 755 by default, to allow non-root users restore backups
themselves.

However, from a security point of view, what kind of data are they
getting access to that they should not have? The actual backup
files and directories have the same permissions as the original, so
there's no gained visibility. Is it just potentially a list of the
files that were backed up? Could the incremental data have the file
permissions as the original?

Yes, the 700 on the rdiff-backup-data directory is intentional. The
mirror files have their original permissions, so restores from current
data are already possible.

Opening up the rdiff-backup-data directory would basically provide
access to two additional pieces of information: the mirror_metadata
files, and the increments directory. The mirror_metadata files
contains information on every file, so we don't want that
world-readable.

Although increments already have the permissions and ownership of the
original files they represent, the structure of the increments
directory structure leaks information. To correct this, I suppose
rdiff-backup should look at an increments directory, and allow access
if and only if the user has had access at every time rdiff-backup was
run. But this would be a pain, and unix permissions aren't flexible
enough to do this anyway. Finally, the diffs themselves may leak
information [long-winded complicated example of this deleted].


--
Ben Escoto

Ben Escoto wrote:
Blair Zajac <blair < at > orcaware.com>
wrote the following on Sat, 12 Nov 2005 19:41:10 -0800
Yes, it appears that the problem is that rdiff-backup's data
directory is 700, which prevents normal users from reading it.

I'm guessing that this is this intended? I would be nice for it to
be 755 by default, to allow non-root users restore backups
themselves.

However, from a security point of view, what kind of data are they
getting access to that they should not have? The actual backup
files and directories have the same permissions as the original, so
there's no gained visibility. Is it just potentially a list of the
files that were backed up? Could the incremental data have the file
permissions as the original?

Yes, the 700 on the rdiff-backup-data directory is intentional. The
mirror files have their original permissions, so restores from current
data are already possible.

Opening up the rdiff-backup-data directory would basically provide
access to two additional pieces of information: the mirror_metadata
files, and the increments directory. The mirror_metadata files
contains information on every file, so we don't want that
world-readable.

Although increments already have the permissions and ownership of the
original files they represent, the structure of the increments
directory structure leaks information. To correct this, I suppose
rdiff-backup should look at an increments directory, and allow access
if and only if the user has had access at every time rdiff-backup was
run. But this would be a pain, and unix permissions aren't flexible
enough to do this anyway. Finally, the diffs themselves may leak
information [long-winded complicated example of this deleted].

Good point about permissions changing over time for each user. That makes the
problem harder. Definitely easier to leave the rdiff-backup directory at 700!

Blair