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

[Oliver Hookins]

On Wed Jun 11, 2008 at 12:52:23 -0400, Andrew Ferguson wrote:
> On Jun 11, 2008, at 12:50 AM, Oliver Hookins wrote:
>
>> Hi,
>>
>> some more on this issue which we still get a LOT of problems with. It 
>> seems
>> nobody really cares about this issue, since nobody has replied.
>>
>> When we get permission denied on files that have restrictive  
>> permissions on
>> the source due to performing the backup as a non-root user on the
>> destination, if there was an option to not store permissions natively 
>> this
>> could fix the problem.
>>
>> I notice 1.1.15 has a "--no-acls" option which completely prevents  
>> backing
>> up ACLs. Would it be possible to add a "--no-native-acls" option which 
>> only
>> stores permissions in the meta-data? It would be supremely useful...
>
> Oliver,
>
> 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?

This could be a valid workaround for the moment...

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

>
> Regarding a "--no-write-acls" option: That would certainly be possible  
> as there is already a 'acls_write' global variable which presumably  
> would lead to such behavior (it would need to be tested as well), but it 
> currently gets set destructively by the fs_abilities checks. Somebody 
> would need to write a patch to make the update_triple() function do a 
> better job at not over-writing preset global variables (instead of the 
> current special case for the _active ones, like eas_active, acls_active, 
> etc.)

Interesting. I'll note this down and see if I can put together a patch.

-- 
Regards,
Oliver Hookins
Anchor Systems