A user can access all account :(

Website Rob

Well-Known Member
Mar 23, 2002
Alberta, Canada
cPanel Access Level
Root Administrator
Although I have confirmed the &evil script& will work

include &/home/otheruser/public_html/config.inc.php&;
echo $dbpassword;
echo $dbuser;
etc etc

I dont' agree it is very easy to get data. One must know the &correct & accurate& path to the file -and- the &correct & accurate& mySQL variable names. It maybe easy for common Open Source scripts (PostNuke, etc.) but one can only find out the &correct & accurate& path to the file if a mistake is made in the setup or configuration.

If, we were to agree that the above might be a security breach (most people make some mistakes in setting up these type scripts, causing a default error msg. showing the path), then I, personally, prefer David's suggestion of chmod'ing the directory to 750. I haven't done this yet as I am loathe to disturb a perfectly working setup, unless I know for sure there is an advantage.

The dis-advantage I see with David's suggestion is that everytime a new account is created, one must &remember& to go in and change the settings - no? Is there an automatic way of doing this?

Another question is, changing the directory permissions from 711 (default setting) to 750 (as suggested) does that still allow the scripts to work -- with nothing set for public (which is zero) how do the scripts function?


Well-Known Member
Sep 20, 2002
Toronto, Ontario Canada
cPanel Access Level
DataCenter Provider
When changing to 750 this is what I do;

chmod 750 all /home/ directories
chgrp nobody all directories
vi /etc/group and add cpanel to the group nobody

Now to do this automagically, a small tweak to wwwacct can be done.

I have found this to work flawlessly, though one way to test on your own system would be to modify only one account (test account or such) and see.

I have not had any issues with scripts/languages which when executed run in one of three ways, as user, as nobody (webserver) or as cpanel (updates and such). Since all three ways have at least r/e access to the directories. Even upcp doing it's interchange stuff there are no errors.

Considering if you are going to give shell access to a user, it is usually the main user and they still have full access to all of there stuff, but are denied from snooping in others home areas.

As for malicious users hacking into others config files as sampled earlier, that is a different story, short of running a seperate instance of apache for each user there's not much you can do. The &jailed& option only will stop beginners, anyone with a strong *nix background can break the jail.

There is a saying, the only true secure system is one with no id's and no access at all. The minute you give someone access to a system, you are open to any and all security flaws that may exist.