There is the bwprotect module for apache that prevents /~user to a user through a domain that isn't owned by that user. I am not sure if this is tied to cpanel or looks at permissions, either way its moot.
The option to disable the ability to /~user is not acceptable to us, yet with bwprotect we cannot offer services we wish to offer.
I have developed a solution to both problems, but it requires direct editing of your httpd.conf (For now until cpanel and others pick up on this.)
** end background**
**the follow I initially posted in the cpanel support forum.**
I've developed a work around for the now infamous "511 access not allowed from this domain" error. This isnít going to leave you open for leeching, or deny you the ability to do a shared secure certificate or provide access before propagation occurs.
As we know, the culprit for this problem is the bwprotect module. So letís get rid of that.
Find these two lines in your httpd.conf (most likely found in /etc/httpd/conf)
LoadModule bwprotect_module libexec/mod_bwprotect.so
Comment them out by placing a # in front of them. (I know, itís rudimentary.)
Okay now that we have bwprotect turned off, we have a problem, people can leech bandwidth again from other accounts.
So now we need to turn off the ability to /~user completely.
Find the following section in the server config part of httpd.conf:
Well that solves the problem, now shared certificates work, and Iím sure you can figure out how to apply this to an IP based VirtualHost (or any VirtualHost for that matter!) to allow users access before propagation, or for a customer to leech between his own accounts.
But I have ANOTHER treat for you all! We can control what usernames are allowed to be accessed!
Instead of the above in a VirtualHost section do the following:
And this would expressly deny certain users to be accessed.
Obviously restart apache for the changes to take effect!
With all of the above everybody ought to be able to protect their users bandwidth, while maintaining the ability to have a shared certificate or provide access prior to propagation.
Additionally, you now have control over specifically WHICH users may be accessed this way! This means you can prevent that 5GB a day site from leeching bandwidth through the shared secure certificate (and increasing CPU load because of encryption), or prevent people from abusing the courtesy of providing access before propagation.
I hope everybody has found this fun and informative, as well as very useful. I would like to point out I have already submitted a feature request built around this system. I am sure that we will see a nice way of doing this through WHM in the future as this is obviously a cure for something that has caused a lot of headaches for people.