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

[Oliver Hookins]

On Wed Jun 11, 2008 at 21:55:15 -0400, Andrew Ferguson wrote:
>
> On Jun 11, 2008, at 9:12 PM, Oliver Hookins wrote:
>>> If you're sure that the problem is due to ACLs being stored on the
>>> destination, then why don't you remove the posix ACL python module on
>>> the destination? That would prevent rdiff-backup from writing them...
>>
>> Thanks for your reply Andrew. So are you saying without the posix ACL
>> module, no unix permissions will be written on the destination at all? 
>> So
>> essentially all files written out by rdiff-backup will have the  
>> default
>> permissions as set by the umask?
>
> No. Without the ACL module *only* Unix permissions will be written --  
> the Access Control Lists will not be. The way you posed your question  
> made me think that you believed it was ACLs causing the problem, not the 
> standard Unix permissions.
>
>>> Also, you will need to provide more details on your setup  
>>> (specifically
>>> the UID of rdiff-backup's process on both ends, ACL support, etc.)  
>>> and
>>> the troublesome file(s) -- what are their unix permissions? ACL  
>>> entries?
>>
>> We have the posix ACL python module installed on both the source and
>> destination machines, rdiff-backup runs as root on the source and a  
>> standard
>> user UID on the destination.
>>
>> The troublesome files are usually ones with very restrictive  
>> permissions on
>> the source. For example '/usr/bin/sudoedit' on one machine which is  
>> owned by
>> root:root and has permissions 4111. It can be backed up fine, but when
>> rdiff-backup wants to do something with the backed up file on a later 
>> run
>> (now running as a non-root user) it can't read the file and can't  
>> force the
>> permissions as it is not running as root.
>
> Hmm. For some reason, I had thought that problem was fixed. I'll try and 
> test it out again with the CVS version. It certainly should be able to 
> force the permissions since it shouldn't have tried (or been able) to 
> chown() the destination file to a user other than it's own non-root UID.

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.

-- 
Regards,
Oliver Hookins
Anchor Systems