Prevent users from reading each others webroots when using PHP system functions?

[Sonician]

Hi!

What would be the best way to prevent system functions such as shell_exec, exec and so on from acessing other users webroots, besides actually disabling them? suPHP + open_basedir aren't compatible as it seems.

Any suggestions on what route to take?

/Sonician

[texo]

I'm testing 1h.com's HIVE on some of my servers, and it's working really well. One of the things it does is employ "a chroot mechanism where each user is limited to its own directory". So far, it's looking really good.

[alphawolf50]

The best option is to disable those functions if you can find a work-around. Another option may seem a little crazy, but this is what I've done with mod_fcgid + suEXEC:

1. Edit /etc/group so that "nobody" is in each web users's group. (Only web users!!) So:

useracct:x:537:useracct,nobody

2. Restart Apache

3. Modify permissions (for each account):

# cd /home/useracct/public_html/
# find . -type d -exec chmod 710 {} \;
# find . -type f -exec chmod 640 {} \;
# find . -type f -name "*.php" -exec chmod 600 {} \;

The above will set:

1. read/write/traverse on all directories for the owner, and traverse only for the group (needed because "nobody" is in the group), but no rights for "everyone".
2. read/write for all files for owner, read-only for group (so apache can serve image, html, css, etc), and no rights for "everyone"
3. read/write for PHP files for owner, and absolutely no rights for anyone else. This makes it impossible for apache to ever read a php config script directly and expose your passwords.

As always, test this somewhere unimportant before doing it live. You'll also want to check the permissions within the users home directory and make sure the user's group doesn't have access to places it shouldn't.

[cPanelTristan]

I wouldn't recommend editing /etc/group (or /etc/passwd) manually in any way at all. You can corrupt the file and then no users will be able to function on the system.

Please note that any steps that can possibly put your system into a state of dysfunction along with customizing to the point it doesn't fall under the typical cPanel setup would mean we no longer support that system. If you choose to follow recommendations such as the above without considering this caveat and then break the system, we cannot restore those settings for you. You would want to make certain to have full backups that can be restored to a clean system that hasn't been fundamentally altered.

[alphawolf50]

I did say that the best option was just to disable those functions. But perhaps some additional warning was warranted.

If you break it you're on your own -- test in your own test environment before going live -- and if you don't know how to revert these changes, you should not make them!

Re: Editing /etc/group - I did it manually because it was quicker for multiple accounts, but there is the safer command line option:
(replace webacct with the account)

# useradd -G {webacct} nobody

As said above -- if you do any of this you are on your own re: support.