Description of problem:

If DocumentRoot is a directory with the context type user_home_t, the httpd service fails to start up with the error "DocumentRoot must be a directory".  This is different from its behavior in other incorrect-context-type cases where it starts up successfully (but access to the content in question is still correctly denied).


Version-Release number of selected component (if applicable): 2.2.15-28


How reproducible: 100%


Steps to Reproduce:

1. Create a directory in a user homedir or otherwise assign it a context as though it had been so created.
2. Move the directory to /
3. Configure Apache's DocumentRoot to point to this directory.
4. [Re]start httpd.

Actual results: httpd startup fails with a misleading error.


Expected results: httpd startup succeeds (matching its behavior in other such cases), or fails with an error that gives correct information.


Additional info:

It would be better if Apache just gave a generic but correct error message like "can't access DocumentRoot".  It would be better still if Apache considered the current enforcement status, and if SELinux is enforcing, reported something like "DocumentRoot is not a directory or SELinux is blocking access".  Best would be if it considered enforcement status, looked at the directory context and reported something like "DocumentRoot is inaccessible because of bad SELinux context: type is [foo] but must be [bar]".

I understand Fedora's FriendlyEPERM effort has a similar goal:

https://fedoraproject.org/wiki/Features/FriendlyEPERM

However, for RHEL 6 it is probably better to address this case-by-case without reliance on FriendlyEPERM.