SELinux Enforcing not honouring httpd_enable_homed

Question

Why am I able to access http://localhost/~myusername in Fedora20 with SELinux set to Enforcing, if the httpd_enable_homedirs boolean is set to off?

The following is a direct excerpt from the fedoraproject's wiki on SELinux about the httpd_enable_homedirs boolean:

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.

I have a directory within the /home/user/ directory that I had set up in a prior release(F19) to serve content/files on the server (/home/user/public_html), marked with the label httpd_user_content_t. The directory is owned by reg_user:apache; "regular user" is part of the apache group.

However, based on the SELinux documentation, I had assumed that I would be unable to access http://localhost/~reg_user/ unless the above-mentioned boolean was switched from off to on; yet, I'm able to do so without any prompts/errors while in Enforcing mode. Was my assumption truly flawed to begin with, or might there be a security risk in my local SELinux policy?

BTW: the server's hosted in /var/www

---

Troubleshoot

After changing the group ownership of the directory back to the reg_user's group, there was no noticeable difference in behavior with the httpd_enable_homedirs boolean. However, I have a configuration file for the server that does specify the public_html directory to be served/mapped to http://server/~username:

<IfModule mod_userdir.c>
    UserDir public_html
</IfModule>

along with a <Directory> block containing further restrictions/permissions and access control.

Maybe the server follows these directions at this point regardless of the httpd_enable_homedirs boolean; is the SELinux boolean primarily needed during the initial setup for the searchpath permissions? Since the /home/user/public_html directory is labeled with the correct fcontext (i.e. httpd_user_content_t), that's the only explanation I can come up with to why SELinux is not blocking apache from accessing it.

---

SELinux policy modules

In an attempt to narrow down the possible cause of this inconsistency I issued the following command (as suggested by user @FeRD) that lists custom/irregular SELinux policy files, which were not provided/owned by the selinux-policy-targeted package:

[root@hostname etc]# find /etc/selinux -print0 |xargs -0 -n10 rpm -qf |grep "not owned"
file /etc/selinux/targeted/modules/active/booleans.local is not owned by any package
file /etc/selinux/targeted/modules/active/modules/sandbox.pp.disabled is not owned by any package
file /etc/selinux/targeted/modules/active/modules/sandbox.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/radicale.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/permissive_bluetooth_t.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/mod_selinux.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/mypol.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/gcl.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/copr.pp is not owned by any package
file /etc/selinux/targeted/modules/active/modules/mailgraph.pp is not owned by any package
file /etc/selinux/targeted/modules/active/ports.local is not owned by any package
file /etc/selinux/targeted/contexts/netfilter_contexts is not owned by any package