I started using suPHP recently, and I'm spending an amazing amount of time debugging the configurations and different compile options to get something that actually works. I've tried contacting the development team through their mailing list, but it's obviously made of ghosts...

I am trying to use the chroot parameter, but it trigger a 500 Internal Error which I just can't solve.

I am using DBD MySQL for the DocumentRoot definition:

<VirtualHost *:80>
    ServerName *

    DBDriver mysql
    DBDParams <params>
    DBDocRoot "SELECT document_root FROM domains WHERE name=%s" HOSTNAME

    suPHP_Engine on
    AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
    suPHP_AddHandler application/x-httpd-php

Once the VirtualHost has set the DocumentRoot, suPHP is supposed to apply an additional chroot. See the relevant section of my /etc/suphp.conf below:



The chroot parameters couldn't possibly be simpler, yet suPHP spits:

Caused by SystemException in API_Linux.cpp:465: chdir() failed: No such file or directory

... when I make a request to a PHP script. The suphp log does not contain any information, this line comes from the Apache error log.

Does anyone on Earth actually now how to setup this horrible chroot feature? I've been through countless forums and mails from the listing, but no-one has yet given a proper answer (even though this feature has been patched an unbelievable number of times). Or maybe I should switch to suExec, hoping it'll offer more satisfying results...?


Your problem is caused by the fact that you do not understand how chroot works. Once you chroot into /home/user, that's the new root and the paths are "relative" to it. So, if you have your files in /home/user/public_html and want to chroot to /home/user then the chdir should actually be /public_html and the fastcgi document root would be the same (/public_html).

It is technically impossible for suPHP to run chroot at a farther point in the way to launching the process.

| improve this answer | |
  • I do understand how chroot works. suPHP designers obviously don't. chdir is a call made by suPHP, not my script. It calls it before chrooting. I've spotted two errors in API_Linux.cpp. suPHP throws this error, but the chroot actually happens. However, due to design errors, many other things seem to fail afterwards. – John WH Smith Jul 17 '14 at 17:40
  • Actually you are not right. The chdir is indeed made by suPHP but AFTER chroot. Chroot is being done at the initialization of suPHP while chdir is being done when executing a script, on a per script launch basis. So chdir is executed inside the chroot. – Florin Asăvoaie Jul 17 '14 at 17:53
  • The implementation of the chroot feature makes suPHP unable to find /usr/bin/php5-cgi (since it's already locked into the user's home). It's obviously triggered to early... The chroot call is supposed to be made at script execution, not earlier. Because of this, I just can't find a way to configure it correctly. I can't actually place a copy of php5-cgi into each user home, that'd be ridiculous. – John WH Smith Jul 17 '14 at 17:54
  • I am sorry but I will have to flag your answer and comments as you do not understand how it works. If you want it to work that way, it means that the already launched binary would require to chroot by its own. You need to build a chroot environment with all the libraries and binaries in order to run PHP inside chroot with suPHP. Not to mention that you downvoted an absolutely correct answer. – Florin Asăvoaie Jul 17 '14 at 17:59
  • suPHP is supposed to chroot into home directories. If I follow your reasoning, that means that each home directory has to become a chroot environment, that is, each must contain every single PHP binary. Is that the way you hear it? – John WH Smith Jul 17 '14 at 18:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.