6:14 p.m.
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@bacteria BackupPC]# pwd
/var/lib/BackupPC
[root@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@bacteria bkupdata]# pwd
/bkupdata
[root@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@bacteria jab-opti755]# pwd
/bkupdata/pc/jab-opti755
[root@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