Discussion:
[suPHP] Handler for (null) returned invalid result code 70014
Helmuth Gronewold
2014-07-02 14:32:34 UTC
Permalink
Dear list,

I really need your help with this. I have two webserver clusters with
mod_suphp 0.7.1 and Apache 2.2 (squeeze-lts). BalanceNG is placed
infront of the webservers to load balance user requests in DSR mode. PHP
sessions and data is stored on a reliable NFS server.
Multiple times a day users get an internal server error and the Apache
logs say:


[Wed Jul 02 09:34:32 2014] [error] [client 9x.xx.xx.64] Handler for
(null) returned invalid result code 70014, referer:
http://www.example.com/user_update.php?action=upload&id=292931

In more than two cases the error was reproducible for the user only, but
was gone the next day or after a few hours. Two months ago 6 out of 8
users from one office got this problem and again it fixed itself the
other day.

As you can see, the referer URL above says action=upload. The problem is
not bound to file uploads. Sometimes scripts that could be used to
upload files only changed two values with a few byte in POST size.

It is also not bound to a specific script. I've seen that error with
multiple different scripts which go from mostly flat PHP files with
structural programming to MVC and OOP. The only thing that most of the
scripts have in common is, that they provide file upload functionality
(which is not used every time...).

I've read every website on the six result pages google returned to this
topic. No one found a clear solution to this. Some say a proxy or
firewall is causing this (pfSense and BalanceNG is used here, but there
are equal rules for all users and no content modification), some say
it's specific to the executed PHP code.

In my opinion the most interesting results are:

1.
http://serverfault.com/questions/231331/handler-for-null-returned-invalid-result-code-70007-causing-error-500
2. http://www.webhostingtalk.com/showthread.php?t=1351337

The first one describes what the error means. I've checked out both the
Apache and suPHP codebase and found out that ap_run_handler() returns
this error. The function is implemented by the handler which in turn,
AFAIK, is mod_suphp.

The second ones poster did some nice debugging and found out the
following:

1. mod_security is not an issue (even though I'm not using
mod_security...)
2. POST requests with forms are involved 100% of the time
3. suphp is involved
4. the PHP script itself is not even executed
5. "this error can also be logged if a form's content-size value in the
POST headers does not match the actual content size"

On the other hand I did not get a "Connection Reset" like he posted.

In my understanding the error is generated when there is a communication
problem between Apache and suPHP. But I'm really not sure about that.

Every single advice to track down this problem would be great!

Thanks in advance,

Helmuth
Joe Gillotti
2014-07-03 08:34:09 UTC
Permalink
Helmuth,

Are you using apache/suphp/php compiled from source or from stock
Debian's apt repo? If the latter perhaps you could file this as a debian
bug for those packages, once you have garnered some additional info of
course.

Could you post some of your configs?

Regards,

Joe G
Post by Helmuth Gronewold
Dear list,
I really need your help with this. I have two webserver clusters with
mod_suphp 0.7.1 and Apache 2.2 (squeeze-lts). BalanceNG is placed
infront of the webservers to load balance user requests in DSR mode.
PHP sessions and data is stored on a reliable NFS server.
Multiple times a day users get an internal server error and the Apache
[Wed Jul 02 09:34:32 2014] [error] [client 9x.xx.xx.64] Handler for
http://www.example.com/user_update.php?action=upload&id=292931
In more than two cases the error was reproducible for the user only,
but was gone the next day or after a few hours. Two months ago 6 out
of 8 users from one office got this problem and again it fixed itself
the other day.
As you can see, the referer URL above says action=upload. The problem
is not bound to file uploads. Sometimes scripts that could be used to
upload files only changed two values with a few byte in POST size.
It is also not bound to a specific script. I've seen that error with
multiple different scripts which go from mostly flat PHP files with
structural programming to MVC and OOP. The only thing that most of the
scripts have in common is, that they provide file upload functionality
(which is not used every time...).
I've read every website on the six result pages google returned to
this topic. No one found a clear solution to this. Some say a proxy or
firewall is causing this (pfSense and BalanceNG is used here, but
there are equal rules for all users and no content modification), some
say it's specific to the executed PHP code.
1.
http://serverfault.com/questions/231331/handler-for-null-returned-invalid-result-code-70007-causing-error-500
2. http://www.webhostingtalk.com/showthread.php?t=1351337
The first one describes what the error means. I've checked out both
the Apache and suPHP codebase and found out that ap_run_handler()
returns this error. The function is implemented by the handler which
in turn, AFAIK, is mod_suphp.
The second ones poster did some nice debugging and found out the
1. mod_security is not an issue (even though I'm not using
mod_security...)
2. POST requests with forms are involved 100% of the time
3. suphp is involved
4. the PHP script itself is not even executed
5. "this error can also be logged if a form's content-size value in
the POST headers does not match the actual content size"
On the other hand I did not get a "Connection Reset" like he posted.
In my understanding the error is generated when there is a
communication problem between Apache and suPHP. But I'm really not
sure about that.
Every single advice to track down this problem would be great!
Thanks in advance,
Helmuth
_______________________________________________
suPHP mailing list
https://lists.marsching.com/mailman/listinfo/suphp
Helmuth Gronewold
2014-07-03 10:22:43 UTC
Permalink
Dear Joe,
Post by Joe Gillotti
Are you using apache/suphp/php compiled from source or from stock
Debian's apt repo? If the
latter perhaps you could file this as a debian bug for those packages,
thank you for your response! I'm using stock packages from the Debian
LTS repo, only. I've seen this error 2012, too. It's not a new problem.
Sure, I could file a bug to the debian team.

I'm also using apache2-suexec-custom instead of apache2-suexec:

# aptitude search suexec
p apache2-suexec - Standard suexec program for Apache 2
mod_suexec
id apache2-suexec-custom - Configurable suexec program for Apache 2
mod_suexec
Post by Joe Gillotti
once you have garnered some additional info of course.
Do you have any hints to track this down? What should I do? Because
it's not reproducible I cannot use GDB, strace or something like that.
Could you post some of your configs?
----------------- Snip --------------------
[global]
logfile=/var/log/suphp/suphp.log
loglevel=info
webserver_user=www-data
docroot=/
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
check_vhost_docroot=true
errors_to_browser=false
env_path=/bin\:/usr/bin\:/usr/local/bin
umask=0022
min_uid=10000
min_gid=10000
[handlers]
application/x-httpd-php="php:/usr/bin/php-cgi"
x-suphp-cgi="execute:!self"

----------------- Snap --------------------

This is a part of my vhost-configuriation:

----------------- Snip --------------------
<Directory /var/www/user1/htdocs/>
suPHP_Engine on
suPHP_AddHandler application/x-httpd-php
suPHP_ConfigPath /etc/php5/users/user1/
[...]
</Directory>
----------------- Snap --------------------

There is a php.ini for every user.


This is the suphp.conf from apache2/mods-enabled/
----------------- Snip --------------------
<IfModule mod_suphp.c>
AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php

<Directory />
suPHP_Engine on
</Directory>

<Directory /usr/share>
suPHP_Engine off
</Directory>

</IfModule>
----------------- Snap --------------------


Again, thank you for your help!
Joe Gillotti
2014-07-03 10:32:07 UTC
Permalink
Hey,

What if you try disabling/uninstalling suexec?

Not many people are completely aware of this but suPHP also works for
executing one-off CGI scripts/binaries (I.E. not php) and can take the
place of suexec.

I know that cPanel likes to enable suPHP and suexec at the same time but
I'm very sure it patches them a bit.

Read the second item in this with regards to using it to replace suexec:
http://debianaddict.com/2011/08/19/usually-ignored-features-of-suphp/

Joe
Post by Helmuth Gronewold
Dear Joe,
Post by Joe Gillotti
Are you using apache/suphp/php compiled from source or from stock
Debian's apt repo? If the
latter perhaps you could file this as a debian bug for those packages,
thank you for your response! I'm using stock packages from the Debian
LTS repo, only. I've seen this error 2012, too. It's not a new problem.
Sure, I could file a bug to the debian team.
# aptitude search suexec
p apache2-suexec - Standard suexec program for Apache 2
mod_suexec
id apache2-suexec-custom - Configurable suexec program for Apache 2
mod_suexec
Post by Joe Gillotti
once you have garnered some additional info of course.
Do you have any hints to track this down? What should I do? Because
it's not reproducible I cannot use GDB, strace or something like that.
Post by Joe Gillotti
Could you post some of your configs?
----------------- Snip --------------------
[global]
logfile=/var/log/suphp/suphp.log
loglevel=info
webserver_user=www-data
docroot=/
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
check_vhost_docroot=true
errors_to_browser=false
env_path=/bin\:/usr/bin\:/usr/local/bin
umask=0022
min_uid=10000
min_gid=10000
[handlers]
application/x-httpd-php="php:/usr/bin/php-cgi"
x-suphp-cgi="execute:!self"
----------------- Snap --------------------
----------------- Snip --------------------
<Directory /var/www/user1/htdocs/>
suPHP_Engine on
suPHP_AddHandler application/x-httpd-php
suPHP_ConfigPath /etc/php5/users/user1/
[...]
</Directory>
----------------- Snap --------------------
There is a php.ini for every user.
This is the suphp.conf from apache2/mods-enabled/
----------------- Snip --------------------
<IfModule mod_suphp.c>
AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php
<Directory />
suPHP_Engine on
</Directory>
<Directory /usr/share>
suPHP_Engine off
</Directory>
</IfModule>
----------------- Snap --------------------
Again, thank you for your help!
Sebastian Marsching
2014-07-03 14:03:20 UTC
Permalink
Not many people are completely aware of this but suPHP also works for executing one-off CGI scripts/binaries (I.E. not php) and can take the place of suexec.
I seriously recommend not to use suPHP as a replacement for suExec. suPHP does not have the same strict filtering of environment variables that suExec has, so that there might be security issues (e.g. if running Perl scripts).
Joe Gillotti
2014-07-04 01:42:04 UTC
Permalink
Definitely a valid argument, but I don't see why these same concerns
shouldn't apply to running PHP scripts, which are just as capable of
causing damage and using the env variables maliciously as Perl scripts.
Post by Sebastian Marsching
Not many people are completely aware of this but suPHP also works for executing one-off CGI scripts/binaries (I.E. not php) and can take the place of suexec.
I seriously recommend not to use suPHP as a replacement for suExec. suPHP does not have the same strict filtering of environment variables that suExec has, so that there might be security issues (e.g. if running Perl scripts).
Sebastian Marsching
2014-07-04 11:20:11 UTC
Permalink
Post by Joe Gillotti
Definitely a valid argument, but I don't see why these same concerns
shouldn't apply to running PHP scripts, which are just as capable of causing
damage and using the env variables maliciously as Perl scripts.
That is true, however suPHP filters some environment variables (in particular PHPRC and LD_LIBRARY_PATH) that might be problematic for PHP.

The difference between suPHP and suExec is that suPHP uses a black-list and suExec a white-list. If you do not know which kind of executables is run, a black-list obviously is the better approach.
Helmuth Gronewold
2014-07-04 14:18:31 UTC
Permalink
Dear Sebastian,
Post by Sebastian Marsching
Post by Joe Gillotti
Definitely a valid argument, but I don't see why these same concerns
shouldn't apply to running PHP scripts, which are just as capable of causing
damage and using the env variables maliciously as Perl scripts.
That is true, however suPHP filters some environment variables (in
particular PHPRC and LD_LIBRARY_PATH) that might be problematic for
PHP.
The difference between suPHP and suExec is that suPHP uses a
black-list and suExec a white-list. If you do not know which kind of
executables is run, a black-list obviously is the better approach.
I am using suPHP and it works just fine. I'm happy with it. Except the
fact that there is this irreproducible bug that I don't know how to
debug. It would be REALLY helpful if you could drop a statement under
which conditions this error occurs.
Thanks in advance,

Helmuth

Loading...