SELinux has been around for a while in RedHat. SELinux is Mandatory Access Control mechanism. Starting with RedHat 6, the installer automatically sets SELinux to enforcing mode.

When troubleshooting something SELinux is one more thing to keep in mind.

If you are fixing something and you booted with SELinux disabled, all files created since you have disabled it will not have SELinux context (fcontext). This will cause filesystem relabelling, when you turn SELinux back on. This can take a long time and you will lose fcontexts unless you have added them to the policy database.

If you do decide to go this route, you can disable SELinux by passing selinux=0 to init or edit /etc/sysconfig/selinux config file and the reboot.

When troubleshooting, it’s probably better to use getenforce and setenforce commands:

[root@ultra opt]# getenforce
Enforcing

To change SELinux status use setenforce:

[root@ultra opt]# setenforce 0
[root@ultra opt]# getenforce
Permissive

One thing that I forget sometimes is difference between cp and mv commands with respect to SELinux. Moving file preserves fcontext, whereas copying does not, unless you use -a option.

Then there are different booleans that can be read and set using getsebool and setsebool. The key thing to remember is that unless you supply -P option to setsebool, the change will not survive reboot.

If you are suspecting problems with fcontexts, you can use chcon and semanage tools. Using chcon changes context on a file or directory, but the context is not added to policy database, so it will not survive reboot.

[root@ultra opt]# chcon --reference /var/www/html /www

This is handy if you want to quickly test out fcontext. The command applies the same fcontext from /var/www/html to /www.

To make fcontext stick across reboots you have to do something like:

[root@ultra opt]# semanage fcontext -a -t public_content_t '/www(/.*)?'

You will need to substitute desired fcontext in place of public_content_t.

Then there is setroubleshootd, which along with sealert can help you figure out what’s happening. The log file /var/log/messages will contain SELinux messages that setroubleshootd intercepts when it’s running, giving you sealert command to run to see in detail what SELinux violation occurred.

That would be it in a very basic nutshell.

One more thing to remember, if you did something like:

[root@ultra opt]# semanage fcontext -a -t private_content_t '/www/stuff(/.*)?'
[root@ultra opt]# semanage fcontext -a -t public_content_t '/www(/.*)?'

Then during next filesystem relabel /www/stuff will have public_content_t fcontext!