Hi
A few days ago we rebooted a server and found that one of the Logical Volumes would not mount at boot, but mounted cleanly manually.
So I traced the problem to SE Linux. Specifically the context for /dev/mapper/VolGroup01-lv_ staff is wrong.
s -lsahZ /dev/mapper/VolGroup01-* lrwxrwxrwx. root root system_u:object_r:quota_db_t:s0 /dev/mapper/VolGroup01-lv_staff -> ../dm-25 lrwxrwxrwx. root root system_u:object_r:device_t:s0 /dev/mapper/VolGroup01-lv_student -> ../dm-24
I have tried to correct this with the Logical Volume active and mounted using
chcon -v --reference /dev/mapper/VolGroup01-lv_student /dev/mapper/VolGroup01-lv_staff and while this command completes the context is not changed.
Can someone confirm or deny that making the Logical Volume inactive and then repeating the chcon should change the link to the correct context?
Thanks for any insight you can offer.
Can someone confirm or deny that making the Logical Volume inactive and then repeating the chcon should change the link to the correct context?
First off don't use chcon.
What's the output of restorecon -Fvv /path-to-file ?
It seems very odd in the first place for anything in /dev to have an incorrect context given it's a virtual filesystem and as such the contexts handled by the kernel...
Unless of course someone messing about with chcon broke something...
You can also use audit2allow, audit2allow will write allow rule for you.
Thanks
On Thu, Jun 13, 2013 at 5:47 PM, James Hogarth james.hogarth@gmail.comwrote:
Can someone confirm or deny that making the Logical Volume inactive and then repeating the chcon should change the link to the correct context?
First off don't use chcon.
What's the output of restorecon -Fvv /path-to-file ?
It seems very odd in the first place for anything in /dev to have an incorrect context given it's a virtual filesystem and as such the contexts handled by the kernel...
Unless of course someone messing about with chcon broke something... _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 13 June 2013 14:20, Vishesh kumar linuxtovishesh@gmail.com wrote:
You can also use audit2allow, audit2allow will write allow rule for you.
Not a good option in this case considering there's reasonable likelihood of messed up labelling...
While the tool audit2allow will create a module that will allow the activities blocked in the log without case it can cause the system to be opened up to issues...
With the incorrect labelling in the first place (seriously... the base targeted selinux policy in now way should be blocking the mounting of an lvm volume) it could leave you in a ... weird... situation... much better to work out what is causing incorrect labels in the first place...
Doing a quick check of semanage fcontext -l | grep '/dev/mapper' on one of my systems it looks like it should be labelled system_u:object_r:fixed_disk_device_t:s0 ...
OP - what does that show you your system thinks it should be labelled as?
Doing semanage fcontext -l | grep 'quota_db_t' on one of my systems shows that label should be on:
/a?quota.(user|group) /boot/a?quota.(user|group) /etc/a?quota.(user|group) /var/a?quota.(user|group) /var/lib/openshift/a?quota.(user|group) /var/lib/stickshift/a?quota.(user|group) /var/spool/(.*/)?a?quota.(user|group)
So it looks like someone has been playing silly buggers with contexts ... the main question then is if they added it to the system policy via semanage fcontext or if they did chcon ... if the former then it'll need to be cleared out the policy (double check if they did by looking in /etc/selinux/targeted/contexts/files/file_contexts.local ) but if the latter a restorecon (or fixfiles but restorecon probably nicer to use) should fix it.
-
Clint Dilks -
James Hogarth -
Vishesh kumar