SuPHP and shared code

[larryl]

We have successfully upgraded to apache2/php5/suphp and stamped out all of the little flare-ups. The last thing I need to work out is how to give access to several shared packages we offer to our customers.

Using apache1/php4/phpsuexec these were installed to /usr/local/share, chmod'ed to root:wheel, and configured to look for very small local files in each site user's home directory. Aliases in httpd.conf pointed users to the shared software using their own URL's. SuPHP is very unhappy with this arrangement - the UID's are above the minimum, not owned by the site users, etc, etc. Is there a viable way to get SuPHP to execute this shared code without gutting the very nice security features it implements? Short of that, can I get Apache to invoke php some non-SuPHP way only when calls to these specific aliases are made from the virtual sites but use SuPHP for all other php requests?

[djbob2]

Unfortunately, I had this same problem a while back and found no solution. There is no way of configuring suPHP to ignore specific files, directories, users, etc.

A few options you have here:
1) Add this site software to the cPanel skeleton directory so that it is created once for every new account. That might take a substantial amount of disk space though, but it would be contained within your users' quotas and they could delete the apps if they didn't need them.
2) Install these programs within cPanel. That way these could use cPanel's internal PHP, which is a different build and does not use suPHP.
3) Install both PHP 5 and PHP 4 through Easyapache, and use one through suPHP and the other through CGI/FCGI/DSO. This can be configured about the build by going to Service Configuration -> Configure PHP and Suexec. On newer versions of WHM this page pops up in an AJAX pop-up after a successful build anyways.
4) Manually install two copies of PHP 5.

If your internal scripts can work with PHP 4, I recommend option #3. Perhaps option #1 if your apps are small and don't need root privileges.

[larryl]

Thanks for the thoughts. I don't want to install in every site, as upgrades would be ugly and the code would be duplicated everywhere, as you mentioned.

The third and fourth options have promise and were along the lines I was thinking of. Implementation would be the trick - getting apache to use a different method of invoking php when it redirects a user to one of those specific aliases. All of the code will work with php5.

[djbob2]

Does the code work with PHP4? You'll probably just need to configure one extension (ie. .php) for one install, and another extension (ie. .php4) for another install. Then, disable execution path (don't remember if this is in httpd.conf or php.ini) for all but the required path on yourself "unsafe" installation.

[jdlightsey]

Does it allow you to execute the scripts if you disable the paranoid_uid_check and paranoid_gid_check in /opt/suphp/etc/suphp.conf? You might also need to adjust the min_uid and min_gid values if the shared scripts are owned by a system user like nobody or root.

There was a somewhat related issue that came up before about shared scripts that are symlinked into the docroot of a vhost where the symlink owner and the target script owner don't match. Mod_suphp checks for this and throws a security exception regardless of the paranoid_uid_check and paranoid_gid_check settings, but from the way you describe your configuration it doesn't sound like you would encounter this problem.

[larryl]

Installing php4 concurrently has some merit. All of the code will run under either php4 or php5. I might do a manual second install of php5 to run with dso just for those directories, then try to figure out how to get cPanel to keep the necessary httpd.conf modifications through its next round of updates.

I tried removing the paranoid checks and lowering the min UID. That led me to the error that the directory was not owned by the user, which is the site user under SuPHP. I'm sure I could disable that as well, but I really don't want to disable all the security. It would just be nice to exclude it from directories that I have created and explicitly approve.

[verdon]

The problem with installing php4 is that it's end of life is past. There won't be any more support for php4 in terms of security updates from php, and who knows how long cPanel will support it.

[djbob2]

Does it allow you to execute the scripts if you disable the paranoid_uid_check and paranoid_gid_check in /opt/suphp/etc/suphp.conf? You might also need to adjust the min_uid and min_gid values if the shared scripts are owned by a system user like nobody or root.

There was a somewhat related issue that came up before about shared scripts that are symlinked into the docroot of a vhost where the symlink owner and the target script owner don't match. Mod_suphp checks for this and throws a security exception regardless of the paranoid_uid_check and paranoid_gid_check settings, but from the way you describe your configuration it doesn't sound like you would encounter this problem.

suPHP stills makes sure that the target file UID is the same as the runner's UID, as the same for GID. I'm relatively sure there's no way to disable that check. Doing so would pretty much render suPHP useless though. The thing that suPHP really needs to put in as a feature is the ability to tell it allow certain files, users, and groups without checking them.

The problem with installing php4 is that it's end of life is past. There won't be any more support for php4 in terms of security updates from php, and who knows how long cPanel will support it.

The good thing about this situation, though, is that if you know what scripts are being run you can make sure they are secure. PHP 4 seems okay for this situation.