php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67415 PHP-FPM chroot not working in 64 bit
Submitted: 2014-06-10 13:41 UTC Modified: 2014-09-08 19:31 UTC
From: lars at dcmediahosting dot com Assigned:
Status: Not a bug Package: FPM related
PHP Version: 5.4.29 OS: Debian 7.5 64 bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
4 + 15 = ?
Subscribe to this entry?

 
 [2014-06-10 13:41 UTC] lars at dcmediahosting dot com
Description:
------------
We're using PHP-FPM with chroot and execute external binaries like graphicsmagick etc. within chroot, but we're not able to execute binaries or any other command on 64 bit platform. Trying to execute anything on 64 bit gives an exit code 127.

However it's working on 32 bit. So as a temporary solution we're using PHP-FPM on 32 bit with same configuration settings as 64 bit.

Additional information:
nginx 1.4.x is configured with PHP-FPM via TCP on an external PHP-FPM server.




Test script:
---------------
exec('ls -la', $c, $o);

var_dump($c);

var_dump($o);



Expected result:
----------------
64 bit platform outputs:

array(0) { } int(127)

32 bit platform outputs a list of files and folders as it should. 


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-06-10 17:42 UTC] aharvey@php.net
-Status: Open +Status: Feedback
 [2014-06-10 17:42 UTC] aharvey@php.net
Are you sure that your 64 bit chroot is configured properly? Can you run a shell within the chroot and execute ls? (Indeed, is there a shell in your chroot — exec() calls popen() internally, and that will return 127 if the shell can't be executed.)
 [2014-06-10 19:28 UTC] lars at dcmediahosting dot com
-Status: Feedback +Status: Open
 [2014-06-10 19:28 UTC] lars at dcmediahosting dot com
We manage the servers with similar configuration through Chef so configuration should be the same.

Both 32 bit and 64 bit configurations have:
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,

ls -la within chroot /path/to/chroot works. Other binaries work too, wget etc.
(/path/to/chroot is debootstrapped).

Also tried looking at php5-fpm -i but same output on 32/64 bit.
 [2014-08-31 13:52 UTC] lars at dcmediahosting dot com
I have tried to upgrade PHP to 5.4.32, Debian to 7.6, and also the chroot'ed environment, but the problem still exists. I was hoping the problem would magically solve itself later, but this rarely happens :)

Disabling chroot in PHP FPM configuration does make things work as expected on 64 bit platform being able to run external binaries, this however is not a good option so we'll keep running 32 bit PHP instances with chroot configured for now.
  
Is it possible to have a paid review/debug session ?
 [2014-09-08 17:39 UTC] lars at dcmediahosting dot com
In our environment I forgot to bind mount both lib and lib64 on 64 bit! (brain fart!)

mount -o bind /var/opt/chroot/lib /mnt/storage1/domain1/lib
mount -o bind /var/opt/chroot/lib64 /mnt/storage1/domain1/lib64

Now it works :D
 [2014-09-08 19:31 UTC] aharvey@php.net
-Status: Open +Status: Not a bug
 [2014-09-08 19:31 UTC] aharvey@php.net
Terrific; thanks!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 05:01:28 2024 UTC