Switching from Apache: Open_Basedir in the Shared Hosting Environment


Open_basedir, a PHP directive, is ignored by suPHP. LSWS, however, honors open_basdir settings. So, when you move from Apache to LSWS, you may encounter restrictions that, though they were there before, were never honored in your shared hosting environment. Recognizing this difference in Apache and LSWS shows us where to tweak settings to maintain functionality after the switch.


Today a customer reported a problem while running ClipShare (a video sharing application) with LSWS: in a system check, the control panel failed to find the needed binaries for video processing. But, the customer said, there was no problem when they were running Apache. See screenshots below:

The error message shown in the control panel when running LSWS. Open_basedir settings are shown.

No error shown in Apache. Open_basedir settings don’t come up either.

Their server runs CentOS 6.3 x86_64 + cPanel 11.34.0 (build 9) + PHP 5.2.17 + shared hosting.


Seeing the open_basedir settings empty in Apache lead me to think that might be where the problem is. Further investigation showed the following errors in the PHP error log under the docroot:

23-Nov-2012 19:29:42] PHP Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/usr/local/bin/php) is not within the allowed path(s): (/home/example:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/example/public_html/siteadmin/modules/index/check.php on line 81

[23-Nov-2012 19:29:42] PHP Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/usr/bin/mencoder) is not within the allowed path(s): (/home/example:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/example/public_html/siteadmin/modules/index/check.php on line 83

So open_basedir is restricting access to /usr/local and /usr/local/bin because they’re not included in open_basedir. LSWS honors open_basedir settings in the shared hosting environment. We can see these settings if we look at httpd.conf:

ServerName example.com
ServerAlias www.example.com

php_admin_value open_basedir “/home/example:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp”

The question is: Why didn’t the customer see this problem when they were running Apache? I Googled open_basedir and suPHP. (I’m looking into suPHP because the customer is using shared hosting.) I found that open_basedir does not work with suPHP unless it is defined in per user dir php.ini (which it was not in this case).

By default openbase could not be enabled with suphp because suPHP restrict php directives to php.ini.

To get open_base to work with suphp you need use own php.ini for each user account as described in Eeasyapache3 documentation.

That’s it! In Apache (suPHP), the open_basedir settings defined in the vhost section were being ignored. These restrictions had been in place, but they’d been disregarded. With LSWS, though, the open_basedir defined in vhost was now honored and the restrictions on /usr/bin and /usr/local/bin took effect.


Our biggest priority is to restore functionality to the application. We want to replicate the behavior we had with Apache and make sure the site runs without bugs. Apache (using suPHP) does not honor open_basedir, so there’s no reason to have open_basedir set in the first place. We can just disable open_basedir in WHM/cPanel (or remove the open_basedir definition in vhost) as shown below:

Tweaking open_basedir in cPanel

If going through the GUI is too much of a hassle, you can also edit templates from the command line. There you can make either a universal template or a template for a single virtual host:


This problem spotlights a difference between suPHP and LSPHP in the shared hosting environment. LSPHP honors open_basedir for security purposes, while suPHP (Apache) simply ignores them. This concerns me. Without open_basedir restrictions, how many people can see your stuff without your permission? LSPHP maintains this security in the shared hosting environment. Hopefully, Apache will adapt to do the same.

Related Posts