Here's a tutorial approach to the SELinux case:
Find out if SELinux is active:
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
If so, some comparative checking might help. For instance, a server has a default DocumentRoot at
/var/www/html, but we want it somewhere else like
If SELinux is not actively messing with the resource,
ls -dZ on the directory will show something like:
$ ls -dZ /path/to/document/root
On the other hand, if SELinux contexts are applied,
ls -dZ looks more like:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
If we compare to a working DocumentRoot, it would look something like:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
_t relate to
--type) arguments to
chcon. Here is a cut-down man page:
chcon - change file security context
chcon [OPTION]... CONTEXT FILE...
chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
chcon [OPTION]... --reference=RFILE FILE...
Change the security context of each FILE to CONTEXT. With --reference,
change the security context of each FILE to that of RFILE.
use RFILE's security context rather than specifying a CONTEXT value
operate on files and directories recursively
At first guess, the following might seem to work, but might not.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
If the web server still cannot see the DocumentRoot, note that the context matters all the way back to root:
$ sudo chcon -R -t httpd_sys_content_t /path/to/document
$ sudo chcon -R -t httpd_sys_content_t /path/to
$ sudo chcon -R -t httpd_sys_content_t /path
At this point, the web server can see the directory.
Yes, I learned the hard way tonight.
NOTE: The use of chcon conceptually has a downside per RedHat documentation (5.6.1. Temporary Changes: chcon) that states:
The chcon command changes the SELinux context for files. However, changes
made with the chcon command do not survive a file system relabel, or the
execution of the restorecon command.
Use semanage and restorecon to make more permanent changes. A brief example:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
$ sudo restorecon -FR /path/to/document/root
With regards to restorecon, note that -F is required to affect the whole context (i.e. user and type). Also, -R means to make changes recursively. Arguments -v or -p can show progress in either a verbose or terse fashion. Use -FRnv to see what would happen without actually making any changes.
Once semanage is used in this way, it is possible to view local security changes with a command like:
$ sudo semanage export
The output of semanage export may be saved and used by semanage import to make it easier to apply a set of changes to various systems.
NOTE: This answer provides a most basic type context for a site. Security can be much more granular. For example, see a list of types that can apply to web server pages with a command like:
$ seinfo -t | grep http
NOTE: Utilities like semanage and seinfo may not be installed by default. At least on some distributions, required packages may be named something like this: