Thanks

“httpd by default is not allowed to access users home directories. If
you want to allow access to users home directories you need to set the httpd_enable_homedirs boolean and change the context of the files that you want people to access off the home dir.

setsebool -P httpd_enable_homedirs 1
chcon -R -t httpd_sys_content_t ~user/public_html”

Maybe I misunderstood something or should it be updated?
About the missing ‘-P’, it was a typo in that line, yes.

[1] http://fedoraproject.org/wiki/SELinux/apache

You should not “chcon -R -t httpd_sys_content_t ~/public_html”.

There is already a file context specified system wide for ~/public_html.

matchpathcon /home/dgrift/public_html
/home/dgrift/public_html staff_u:object_r:httpd_user_content_t:s0

This is the type that httpd_t can read and SELinux restricted users can interact with in the user home.

There is one thing to consider: If you operate in a Gnome environment than there is a program called restorecond -u running in the gnome-session. That program monitors objects in your user home directory and if required restores their context to the context that is specified system wide for that location.

So if you create ~/public_html it should in that case almost immediately get type httpd_user_content_t. That is because that is specified system-wide and restorecond -u makes sure that the objects in your user home directory are correctly labelled.

What happens is: you create ~/public_html. That directory gets created with the type of generic user home content (user_home_t). Restorecond -u notices that the directory is misslabeled and restores it to the context specified system wide for that location.

So in a Gnome environment you should not have to run the restorecon command manually.

In a text environment there is no restorecond -u running, thus users should manually restorecon -R -v ~/public_html

The type httpd_sys_content_t is a type designed for system content (/var/www) that httpd can read.

It is not designed for content in ~, but in many cases it does work.

Once you start restricting users with SELinux , you will notice that these restricted users are not permitted to interact with objects labelled httpd_sys_content_t.

They are however permitted to interact and use type httpd_user_content_t.

About chcon. Contexts set using chcon are not persistent. When you relabel or run the restorecon command on a location that has been “chcond”, than the context of the location will be reset to the context that is specified system-wide (for example using semanage fcontext)

Not everyone will agree with this: but privileged users should use the semanage command where ever possible to specify file contexts (because its persistent). Unprivileged users can use chcon wherever they are permitted to (will be overriden by similar contexts specified using semanage)

The default file context specification for ~/public_html is:

# matchpathcon /home/dgrift/public_html
/home/dgrift/public_html staff_u:object_r:httpd_user_content_t:s0

Apache can read that. No need to use type: httpd_sys_content_t.

There is one consideration:

In a Gnome environment a program called restorecond is running in the gnome session. This program monitors objects in your $HOME and restores file contexts to the contexts specified if required.

So if you create directory ~public_html and do ls -alZ ~/public_html
it should have type httpd_user_content_t. (the directory is created with type user_home_t (the generic type for user home content), but restorecond -u immediately notices a directory with a context that does not match directory/context defined, and restores it to defined file context (httpd_user_content_t)

If you run in a text only environment, then there is no restorecond -u to watch, and so you or your users should run the restorecon command on ~/public_html. That will reset the context of the location to what is specified system wide.

restorecon -R -v ~/public_html

Using httpd_sys_content_t might in some cases work but it is a wrong type to use because (confined) users do not have permission to interact with that type. You will not notice this in default configurations because users are unconfined (unrestricted).