PHP file_exists() function returns false on /usr/bin/mysql

Question

I've read numerous posts on this problem and none of them matches my problem exactly. I have a WordPress site (currently 3.5) on a GoDaddy virtual host. In November I opted to upgrade the O/S from CentOS 5 to CentOS 6.3, which involved a full O/S reinstall over which I had no control and about which I had no information. Following the O/S reinstall I rebuilt the site from a backup I had taken just before starting.

After the rebuild, a WordPress plugin we've been using for years, WP-DBManager, suddenly stopped backing up our mysql database. The backup fails because the backup panel claims "MYSQL path does NOT exist." Annoyingly, when you go to the DB Options page and tell it to auto-detect the mysql path, the options page produces /usr/bin/mysql, which is correct. I can log into the site with SSH and there it is. The permissions are:

-rwxr-xr-x 1 root root 338184 Jun 22 05:58 /usr/bin/mysql

This SHOULD work. SOMETHING in my site permissions changed with this rebuild and I don't know what; so far I've only documented WordPress configurations. The research I've done suggests it may be something to do with PHP safe mode. We run PHP 5.3.3, and the configuration list from phpinfo() does not show

--enable-safe-mode

which means safe mode should be OFF. The safe mode settings in php.ini when this started were:

safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
safe_mode_exec_dir = 
safe_mode_include_dir = 
safe_mode = off
safe_mode_gid = off

I have since changed safe_mode_gid to ON, with no effect. I have a test site built from the production site, where safe_mode_include_dir = ~ so I tried that, with no effect. The test site runs PHP 5.3.14 and the safe mode settings above were identical except for safe_mode_include_dir. I checked the ENV variable and /usr/bin is included in the PATH:

PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/lrservice/bin

I don't know if this is an environment variable problem, here are the safe mode entries for that:

safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH

These settings are not all the same on the working test site, one reads:

safe_mode_allowed_env_vars = PHP_ LANG LANG_

Since the site is fully functional except for this, I know that mysql's permissions are generally correct. Does this ring any bell for anyone?? Why am I getting all this if safe mode is officially turned off? I have a feeling there's something obvious and stupid that I'm missing.

Answer 1

You have access to the mysql binary from an ssh session in the /usr/bin directory, but php is unable to find it at that same location. I am assuming that your system is using the apache2 webserver.

Is the ChrootDir directive present in the apache configuration file (usually located at /etc/httpd/conf/httpd.conf)?

If that's the case, you can check in the directory pointed by this directive if there is a link to the mysql binary. If not, simply add it by executing the following command (assuming you have the priviledges to do so) in your ssh session:

$ ln /usr/bin/mysql /chroot/path/usr/bin/mysql

with /chroot/path replaced by the ChrootDir directive path.

---

One of the comments mentions the open_basedir PHP setting, which can be configured either in php.ini, httpd.conf, or .htaccess files.

This setting limits access to certain directory of the filesystem available to PHP. A possible fix is to remove this restriction for the scripts executed by the plugin you are using, if that setting is not protected:

• locate the scripts installed by the plugin in your wordpress directory,

• create a .htaccess file lifting the restriction in the directory containing the scripts with the following commands:

  $ echo 'php_value open_basedir none' >> .htaccess

The above will add the text between simple quote at the end of the .htaccess file, creating it if necessary. This solution is probably the safest, as it reduces the security relaxing to only these scripts. You should be wary that you are going to let these scripts potentially have access to much more than they really need to operate.

If the above does not work, it means that the setting is protected, and must be changed in either httpd.conf or php.ini which should be both located within the /etc directory. See this SO question for details.