Re: [rdiff-backup-users] SELinux preventing rdiff-backup

[Andrew Ferguson]

On Mar 4, 2009, at 11:42 AM, Matthew A. Thompson, Contractor, Code  
6189 wrote:
> The heavens stretched forth and Andrew Ferguson decreed the  
> following on or about 03/04/2009 10:20 AM:
> > Ah, ok syscall=188 means that this is happening during setxattr(2).
> > Can you try backing up a simple directory with one file in it, and  
> > use the -v6 option to rdiff-backup? I believe you should get a line  
> > that looks like:
> > "Warning: unable to write xattr security.selinux to /my/test.bak/ 
> > file"
> > Is that the case? If so, then that suggests that rdiff-backup could  
> > simply skip setting security.* extended attributes on the  
> > destination files, just as it already skips the system.* namespace.
>
> You are correct, sir, as seen below.  That said, your final  
> paragraph is  Greek to me... SELinux is confusing and rdiff-backup  
> is confusing, both together...ACK! (One thing I can say is that if  
> you use --no-eas and --no-acls, there is no SELinux warning, but is  
> that a good thing to do?)
>
> To wit, I used a Cobol directory with one file, hello.cob, and:
>
> # rdiff-backup -v6 --no-acls /home/USER/Cobol/ /media/LaCie/trial/ 
> Cobol
> Warning: unable to write xattr security.selinux to '/media/LaCie/ 
> trial/Cobol/rdiff-backup.tmp.1'
> Warning: unable to write xattr security.selinux to '/media/LaCie/ 
> trial/Cobol'

Ok, great. Can you also run this test?

# rdiff-backup -v6 --no-acls /home/USER/Cobol/ /home/USER/Colob.test/

(that is, backup to the same filesystem) I am wondering if it is at  
all possible to maintain the security.selinux extended attributes. And  
can you also try that test as root?


The reason --no-eas fixes it is because with that switch, rdiff-backup  
will not attempt to read any of the extended attributes (for example,  
security.selinux) during the backup. The error occurs when rdiff- 
backup tries to set that attribute on the destination.


On at least Linux and Mac OS X, the extended attributes are also used  
as the storage location for special system information, such as the  
access control lists, or SELinux context. Those attributes are  
identified by reserved namespaces (aka "prefixes").

On Linux, extended attributes can only exist in these four namespaces:  
system.* , security.*, trusted.*, and user.* ... regular users can  
always adjust the user.* namespace, the kernel is reserved the  
system.* namespace and can give users access selectively (for example,  
users can adjust it system.* EAs by using the ACL API), and only the  
superuser can adjust the trusted.* namespace. If SELinux is not  
loaded, then regular users can read the security.* attributes, and the  
superuser can adjust them. If SELinux is loaded, then SELinux controls  
it and users are required to go through the SELinux API. See 'man 5  
attr' for more information.

Mac OS X places no requirements on the naming of extended attributes,  
except that it reserves the com.apple.system.* namespace for ACLs and  
the like. However, on OS X, the kernel does not even expose that  
namespace outside the kernel, and thus rdiff-backup can't ever get in  
a situation where it can see/read extended attributes that it can't  
write.

I guess what this situation is crying for is a better set of tests  
when run under Linux, to determine which namespaces it should or  
should not try to preserve.


Andrew