Dominick -
Thanks for the education. Your advice was following the direction I was
thinking to go, but that gave me confirmation that I was making the right
decision. In the end I checked to see if there was a specific file context
for BackupPC (#seinfo -t will list all the type contexts available). Since
there was not a specific file context for BackupPC, I elected to apply the
same context that is at the default BackupPC file storage location to my
non-standard location at /bkupdata. So in the end this was solved by
applying the following two commands:
#semanage fcontext -a -e /var/lib/BackupPC /bkupdata
#restorecon -R -v /bkupdata
I then rebooted the system just to make sure that everything checks out
after a reboot, and it works as expected. Thanks for your assistance.
Jeff Boyce
Meridian Environmental
www.meridianenv.com
----- Original Message -----
From: "Dominick Grift" <dominick.grift@xxxxxxxxx>
To: "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx>
Cc: "SELinux Fedora List" <selinux@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, March 16, 2013 1:55 AM
Subject: Re: Issue with SELinux and BackupPC backup directory at
non-standard location
On Fri, 2013-03-15 at 16:14 -0700, Jeff Boyce wrote:
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:
The AVC denials all have some things in common:
1. the source type of the operation is httpd_t
2. the target type of the operation is default_t
httpd_t is the webserver process type.
default_t is a special type. This type is assigned to locations unknown
to SELinux.
In this case SELinux is not aware of your exotic "/bkupdata" mountpoint.
Everything on a system is classified using types. That way SELinux knows
if and what access it should grant to any given source.
So what you should do is, you should classify /bkupdata and the content
in there by assigning it an appropriate type.
You should use the existing type for this.
So basically you should look at a existing location that is similar to
your new location and consider using the same type.
There is a command that makes it easy to "clone" file contexts but it
has its limits (you cannot nest them and so use them wisely)
I will give you one very simple example:
lets say that the /bkupdata is really just the same as /var but just in
a exotic location. That would mean that you could clone the file
contexts for /var and use them on /bkupdata as well.
man semanage has an example of how to use the fcontext uquivalent
functionality:
# semanage fcontext -a -e /var /bkupdata
# restorecon -R -v /bkupdata
That will make the contexts of bkupdata equivalent to that of /var
Remember though that you cannot nest them.
Its up to you to find the appropriate types to use. I do not know the
properties of your /bkupdata location.
I can see a backup directory and i also see that httpd_t is trying to
access content on your /bkupdata mountpount.
You may be able to fix this by just using the backupc_var_lib_t ( i am
not even sure if that type exists) type for the whole mountpount:
semanage fcontext -a -t backuppc_var_lib_t "/bkupdata(/.*)?"
restorecon -R -v -F /bkupdata
----
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
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
