What is really going on behind the scenes is that restorecon, by default, even with the -v (verbose) switch is only going to spit out messages about files that it successfully relabels. It will not tell you that a file was looked at, but restorecon did not choose to relabel the file.
Note: This may be something strange with the server's booleans as the hosting company gave us a slightly customized Red Hat Enterprise Linux 5.6 install. We had to bend their arm a bit to let us enable SELinux in enforcing/targeted mode as their support people don't grasp the concept.
To test this, create a folder under /mnt like "test". Then manually relabel it as httpd_sys_content_t using chcon. Now attempt to use restorecon to fix the incorrect label.
# cd /mnt
# mkdir test
# chcon -t httpd_sys_content_t test
# ls -ldZ test
drwxr-xr-x root root user_u:object_r:httpd_sys_content_t test
In order to get restorecon to tell you what is really going on, you have to tell it to be extra verbose with "-vv".
# restorecon -vv test
restorecon: /mnt/test not reset customized by admin to user_u:object_r:httpd_sys_content_t:s0
Ah hah! Now we have some details. Since we now know that restorecon is being blocked due to the file/directory context being "customized", we can use the "-F" switch on restorecon to force the file context label to match the official policy.
# restorecon -vv -F test
restorecon reset /mnt/test context user_u:object_r:httpd_sys_content_t:s0->system_u:object_r:mnt_t:s0
# ls -ldZ test
drwxr-xr-x root root system_u:object_r:mnt_t test
So, if restorecon seems like it is being stubborn and will not relabel your files, try looking at what is going on using the "-vv" and then forcing the issue with "-F". If you want to see what policies might apply to the file in question:
# semanage fcontext -l | grep '/mnt'
/mnt(/[^/]*) symbolic link system_u:object_r:mnt_t:s0
/mnt(/[^/]*)? directory system_u:object_r:mnt_t:s0
/mnt/[^/]*/.* all files <<none>>
No comments:
Post a Comment