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

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

Re: [rdiff-backup-users] 1.1.2 restore error with readonly backup


From: Ben Escoto
Subject: Re: [rdiff-backup-users] 1.1.2 restore error with readonly backup
Date: Sat, 12 Nov 2005 23:42:52 -0600

>>>>> Blair Zajac <address@hidden>
>>>>> 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

Attachment: pgpEQe6sXkke9.pgp
Description: PGP signature


reply via email to

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