Issue with SELinux and BackupPC backup directory at non-standard location

[Jeff Boyce]

Greetings -

I have been testing BackupPC for my small office network, with BackupPC 
running from its own VM.  The backups created by BackupPC are being put on a 
seperate mounted LVM partition (/bkupdata), rather than at /var/lib/BackupPC 
for the standard installation.  I followed the BackupPC documentation for 
doing this, and everything was testing fine.  I extended the logical volume 
and filesystem containing the /bkupdata partition to allow more room for all 
the expected backups after testing was completed.  When I rebooted after 
extending the filesystem, I noticed that SELinux was doing a relabel on the 
filesystem.  I didn't think anything of it until a few hours later when I 
accessed the BackupPC web interface and couldn't see the previous backups. 
After a fair amount of research about potential BackupPC specific causes, I 
was able to determine that the issue was SELinux related.

1.  Everything worked properly (with the non-standard backup location) 
before the reboot and SELinux relabel.
2.  Temporarily turning SELinux off (setenforce=0), and everything works 
again.
3.  Turning SELinux on (setenforce=1), and I get errors from BackupPC web 
interface

I posted to the BackupPC mailing list yesterday, but have no responses from 
anyone with SELinux expertise, so I thought I should take my issue here.  So 
in summary, here is what I have:

Backups are being stored on separate partition, not standard for BackupPC:
/bkupdata

Standard BackupPC storage location:
/var/lib/BackupPC

SELinux context on standard BackupPC storage location:
[root at bacteria BackupPC]# pwd
/var/lib/BackupPC
[root at bacteria BackupPC]# ls -Z
drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 cpool
drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 pc
drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 pool
drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 trash

Current SELinux context on my BackupPC storage location:
[root at bacteria bkupdata]# pwd
/bkupdata
[root at bacteria bkupdata]# ls -Z
drwxr-x---. backuppc root system_u:object_r:default_t:s0 cpool
drwx------. root root system_u:object_r:default_t:s0 lost+found
drwxr-x---. backuppc root system_u:object_r:default_t:s0 pc
drwxr-x---. backuppc root system_u:object_r:default_t:s0 pool
drwxr-x---. backuppc root system_u:object_r:default_t:s0 trash

And one of the test clients backup location:
[root at bacteria jab-opti755]# pwd
/bkupdata/pc/jab-opti755
[root at bacteria jab-opti755]# ls -Z
drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 0
drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 1
drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 2
drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 3
drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 4
drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 5
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 backups
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 backups.old
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 backups.save
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 LOCK
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 LOG.032013
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.0.z
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.1.z
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.2.z
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.3.z
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.4.z
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.5.z
-rw-r-----. backuppc backuppc system_u:object_r:default_t:s0
XferLOG.bad.z.old

In reviewing my SELinux contexts listed above, I noticed that the group
assignment for the directories under /bkupdata is root. I have subsequently
changed them to backuppc, and shutdown the backuppc service, shutdown and
restarted the http service, then restarted the backuppc service. The same
errors persist after this change, so the issue was not just with an
incorrect group setting.

Here is a representative sample of the SELinux audit messages that are 
occurring:

----

time->Thu Mar 14 13:35:51 2013

type=SYSCALL msg=audit(1363293351.295:27283): arch=c000003e syscall=2 
success=no exit=-13 a0=1437b70 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 
pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 
sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." 
exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)

type=AVC msg=audit(1363293351.295:27283): avc:  denied  { read } for 
pid=4379 comm="BackupPC_Admin." name="backups" dev=vdd1 ino=4218673 
scontext=system_u:system_r:httpd_t:s0 
tcontext=system_u:object_r:default_t:s0 tclass=file

----

time->Thu Mar 14 13:35:51 2013

type=SYSCALL msg=audit(1363293351.292:27282): arch=c000003e syscall=2 
success=no exit=-13 a0=1437b10 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 
pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 
sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." 
exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)

type=AVC msg=audit(1363293351.292:27282): avc:  denied  { read } for 
pid=4379 comm="BackupPC_Admin." name="LOCK" dev=vdd1 ino=4194307 
scontext=system_u:system_r:httpd_t:s0 
tcontext=system_u:object_r:default_t:s0 tclass=file

----

time->Thu Mar 14 13:36:01 2013

type=SYSCALL msg=audit(1363293361.526:27285): arch=c000003e syscall=4 
success=no exit=-13 a0=1630140 a1=1569130 a2=1569130 a3=21 items=0 ppid=1806 
pid=4400 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 
sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." 
exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)

type=AVC msg=audit(1363293361.526:27285): avc:  denied  { getattr } for 
pid=4400 comm="BackupPC_Admin." path="/bkupdata/pc/jab-opti755/backups" 
dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0 
tcontext=system_u:object_r:default_t:s0 tclass=file

----


I have read through the RedHat SELinux users guide and understand from this 
and looking at the above messages that my target context is probably not 
what it should be for this.  I am hoping someone can guide me to get this 
corrected in a proper way without making a blanket permissive policy.  Also 
I would like to make sure that if I have to expand my partition again, I 
don't want to have to go through the same pain of discovering the problem, 
or have it fixed so that the problem doesn't re-occur.  If any additional 
information is needed please let me know.

Please CC me directly on any replies as I am only subscribed to the daily 
digest.  Thanks.

Jeff Boyce
Meridian Environmental
www.meridianenv.com