1.1.2 restore error with readonly backup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

1.1.2 restore error with readonly backup

Blair Zajac
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.
<[hidden email]>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.2 restore error with readonly backup

Sheldon Hearn
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.

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.2 restore error with readonly backup

Ben Escoto
In reply to this post by Blair Zajac
>>>>> Blair Zajac <[hidden email]>
>>>>> 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

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.2 restore error with readonly backup

Ben Escoto
>>>>> Ben Escoto <[hidden email]>
>>>>> 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

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.2 restore error with readonly backup

Blair Zajac
In reply to this post by Ben Escoto
Ben Escoto wrote:

>>>>>>Blair Zajac <[hidden email]>
>>>>>>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.
<[hidden email]>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.2 restore error with readonly backup

Blair Zajac
In reply to this post by Ben Escoto
Ben Escoto wrote:

>>>>>>Blair Zajac <[hidden email]>
>>>>>>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


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.2 restore error with readonly backup

Ben Escoto
In reply to this post by Blair Zajac
>>>>> Blair Zajac <[hidden email]>

>>>>> 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

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.2 restore error with readonly backup

Blair Zajac
Ben Escoto wrote:

>>>>>> Blair Zajac <[hidden email]>
>>>>>> 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



_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki