Re: [rdiff-backup-users] Re: Permission denied on file in backup repository

[Andrew Ferguson]

On Jun 11, 2008, at 11:12 PM, Oliver Hookins wrote:

> On Wed Jun 11, 2008 at 23:05:15 -0400, Andrew Ferguson wrote:
> > On Jun 11, 2008, at 10:10 PM, Oliver Hookins wrote:
> > > Maybe I've confused you a little. Here is the file on the source:
> > >
> > > address@hidden ~]# ls -la /usr/bin/sudoedit
> > > ---s--x--x 2 root root 164536 Mar  6 22:23 /usr/bin/sudoedit
> > >
> > > Here is the file on the destination:
> > > address@hidden ~]$ ls -la server/usr/bin/sudoedit
> > > ---s--x--x 1 backup backup 164536 Mar  6 22:23 server/usr/bin/ 
> > > sudoedit
> > >
> > > Because this is a standard user, it can't even read the file that it
> > > backed
> > > up earlier. If we only stored the unix permissions in meta-data this
> > > wouldn't be a problem.
> >
> > Ok, I just checked with the CVS version. That situation does not  
> > cause a
> > problem for rdiff-backup anymore.
>
> Great, I'll try it out. What is the new behaviour that prevents the
> situation from being a problem?

Since rdiff-backup is the owner of the unreadable file, it simply  
gives itself read permission on the file for whichever operation it is  
necessary, then re-adjusts the file after it is finished. This way,  
the old behavior is preserved, but the bug is fixed.

Why is the old behavior a good thing? ("---s--x--x 1 backup backup" on  
destination) Because rdiff-backup uses the file's actual metadata in  
the event that the metadata entry is missing or corrupt, and it also  
keeps the whole process more rsync-like.


Andrew