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

[Andrew Ferguson]

On Mar 4, 2009, at 7:33 AM, Matthew A. Thompson, Contractor, Code 6189  
wrote:
> As some may know, I've been having difficulties with the latest  
> NTFS-3G version and rdiff-backup, and that has been taken care of  
> with the latest rdiff-backup version (I assume...Fedora hasn't  
> upgraded yet).
>
> However, I seem to be running into a new problem that seems to have  
> started around when I started using --no-acls.  It's SELinux which  
> is throwing up bajillions of the errors shown below.
>
> Is this due to the --no-acls tag?  Or is there a "chcon" I could do  
> to fix it?

[Before we begin, let me mention that I have limited experience with  
SELinux, and am mostly speculating.]

It's probably unrelated to the --no-acls. That action simply prevents  
rdiff-backup from setting ACLs on the destination side (it still  
records the ACLs on the source, so they can be set during the restore.)

Perhaps changing the filesystem context will fix this temporarily. See  
'man mount' for information about the context=, fscontext=, and  
defcontext= options.

> Summary:
>
> SELinux is preventing rdiff-backup from creating a file with a  
> context of
> unlabeled_t on a filesystem.
>
> Detailed Description:
>
> SELinux is preventing rdiff-backup from creating a file with a  
> context of
> unlabeled_t on a filesystem. Usually this happens when you ask the  
> cp command to
> maintain the context of a file when copying between file systems,  
> "cp -a" for
> example. Not all file contexts should be maintained between the file  
> systems.
> For example, a read-only file type like iso9660_t should not be  
> placed on a r/w
> system. "cp -P" might be a better solution, as this will adopt the  
> default file
> context for the destination.
>
> Allowing Access:
>
> Use a command like "cp -P" to preserve all permissions except  
> SELinux context.
>
> Additional Information:
>
> Source Context                system_u:object_r:unlabeled_t
> Target Context                system_u:object_r:fusefs_t
> Target Objects                rdiff-backup.tmp.9329 [ filesystem ]
> Source                        rdiff-backup
> Source Path                   /usr/bin/python
> Port                          <Unknown>
> Host                          munged
> Source RPM Packages           python-2.5.2-1.fc10
> Target RPM Packages
> Policy RPM                    selinux-policy-3.5.13-46.fc10
> Selinux Enabled               True
> Policy Type                   targeted
> MLS Enabled                   True
> Enforcing Mode                Enforcing
> Plugin Name                   filesystem_associate
> Host Name                     munged
> Platform                      Linux munged
>                              2.6.27.19-170.2.35.fc10.x86_64 #1 SMP  
> Mon Feb 23
>                              13:00:23 EST 2009 x86_64 x86_64
> Alert Count                   1
> First Seen                    Wed 04 Mar 2009 07:23:29 AM EST
> Last Seen                     Wed 04 Mar 2009 07:23:29 AM EST
> Local ID                      0ccf144f-50a1-415c-ab0e-2925423b2efb
> Line Numbers
>
> Raw Audit Messages
>
> node=munged type=AVC msg=audit(1236169409.556:2190): avc:  denied   
> { associate } for  pid=23152 comm="rdiff-backup" name="rdiff- 
> backup.tmp.9329" dev=sdd1 ino=23236  
> scontext=system_u:object_r:unlabeled_t:s0  
> tcontext=system_u:object_r:fusefs_t:s0 tclass=filesystem
>
> node=munged type=SYSCALL msg=audit(1236169409.556:2190):  
> arch=c000003e syscall=188 success=no exit=-13 a0=bb9bd4 a1=1132834  
> a2=11eb6e4 a3=21 items=0 ppid=22261 pid=23152 auid=500 uid=0 gid=0  
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=26  
> comm="rdiff-backup" exe="/usr/bin/python"  
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)


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.


thanks,
Andrew