php5-cgi not working with suphp in Hardy

[Lionel Dricot]

Suphp doesn't work in Hardy. It seems that it is simply ignored and php processes are executed under www-data.

It was working fine under Gutsy. I dist-upgraded a month ago but I discovered the problem only recently (because one of my website was unable to read a config file chmoded to 700). I'm pretty sure it's the dist-upgrade because the suphp log stopped the day I dist-upgraded (approximately at least).

I didn't change anything in the config in the meantime. Also, when investigation the problem, I copied /etc/apache2 /etc/php5 and /etc/suphp from a working Debian installation. It doesn't work under Hardy.

The symptoms are the following :
1) if mod_php5 is enabled, processes run with www-data permissions. phpinfo() returns "Apache 2.0 Handler " as the server API. (when suphp is working, it returns "Cgi/FastCgi" AFAIK

2) if mod_php5 is not enabled, you will receive an error 500. The logs contain the following lines :
[Wed Jul 30 14:31:55 2008] [error] [client 212.190.219.18] SecurityException in Application.cpp:440: Handler not found in configuration
[Wed Jul 30 14:31:55 2008] [error] [client 212.190.219.18] Caused by KeyNotFoundException in Configuration.cpp:234: Handler "application/x-httpd-php" not found
[Wed Jul 30 14:31:55 2008] [error] [client 212.190.219.18] Premature end of script headers: index.php

If both suphp and php5 are disabled, then your browser offers you to download the file (which is normal).

Also, it has to be noted that suphp is well active because if you try to access a software not in the defined root, you will get an error in the logs. So, it seems like the problem is not suphp but the cgi part of php5 which is not responding or something like that.

I'm not an expert so I'm not sure about the where to assign this issue.

[Lionel Dricot (ploum-deactivatedaccount)]

In fact, it seems that, unlike in Debian, libapache2-mod-php5 takes precedence over suphp. It means that you cannot install both and use suphp only on specific locations because mod-php5 will be called.

In Debian, this is not the case.

[dx9s (dx9s)]

It's worse.. it has to do with the security patch applied (something to do with symlink or something).

I've isolated the bug to this patch. (this is how I did it):

Hardy (as of Aug 7th even) w/ "current" suphp 0.6.2-2ubuntu1 fails

I went ahead and download the source and make my own .deb for 0.6.2-1ubuntu1 (aka made a "hardy" version of libapache2-mod-suphp_0.6.2-1ubuntu1_i386.deb and suphp-common_0.6.2-1ubuntu1_i386.deb)

and removed 0.6.2-2ubuntu1 and installed 0.6.2-1ubuntu1 and the SAME apache configuration (which includes suphp options) works and executes files fine.

upgrade back to the offical "current" 0.6.2-2ubuntu1 and it fails about not just the PARENT directory but ALL grandparent directories not being owned by the same UID as the php script. This is a serious bug the "patch" fixed as it is impossible to give all parent directories over to a particular UID ... at some point it must be owned by .... hmmm lets say "ROOT" !!!! (UID 0)

I don't think the patch was well tested before it was accepted into fixing whatever problem it claims to fix.

so until the maintainers of suphp and the maintainer of the .deb packages for hardy (if you have gutsy, they haven't back ported that patch to it so STAY with gutsy if you use suphp) get together and figure out where this patch has failed -- it will never get fixed....

or do what I did and roll back to older .deb !! (I mean a) update/patch suphp and have it NOT work or b) roll back suphp and have it work with possible [minor] security issue)

PLEASE READ CLOSELY .. it's the patch that was introduced between 0.6.2-1ubuntu1 and 0.6.2-2ubuntu1 (see CVE-2008-1614 "Fix race condition in symlink handling")

In my case.. I have /var/www (UID root) ... /var/www/"site-name" (UID www-data, same as apache UID) and /var/www/"site-name"/htdocs/..../folder (UID X where "X" is same UID as script that executes in that folder)...

With the patch applied. all parent folders must be owned by UID X (/var/www , /var/www/"site-name", /var/www/"site-name"/htdocs, /var/www/"site-name"/htdocs/..../folder <--- all must be owned by UID X for script in "folder" to work) -- this is a serious break-age of suphp!!!!

--dx9s (Doug)

[dx9s (dx9s)]

FWIW: *THEY* (including Steffen Joeris) thinks the problem is fixed... and that all web documents are to be owned by root.. (mind you I make the config file owned by root and log files and so forth) .. or that "ONE" person that needs to run a script but they can't place it anywhere because the folder must be owned by them or root.

(it's a catch 22 -- the patch is not much better than using the build in suexec inside apache).

read more here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475431

and try NOT to get irritated!

[Harry Sufehmi (harry-sufehmi)]

dx9s - I think I'm experiencing this bug as well. Could you be as so kind to upload your version of suphp packages here, so we can see if it resolves our problem too?

Thank you.

[dx9s (dx9s)]

I think this should work (however in my case, I compiled from source):

Download '*0.6.2-1ubuntu1_i386.deb' files (as listed below in the deb -i) from launchpad

(might need current version on the purge statements)

% sudo apt-get purge libapache2-mod-suphp
% sudo apt-get purge suphp-common
% deb -i suphp-common_0.6.2-1ubuntu1_i386.deb
% deb -i libapache2-mod-suphp_0.6.2-1ubuntu1_i386.deb

(I added my files attached below in case the ones from launchpad don't work)

[dx9s (dx9s)]

download the link above
    * (technically unchanged) .deb files with older code made on a Hardy machine (70.1 KiB, application/x-debian-package)

(should be suphp-common)

and libapache2-mod-suphp from here!

[Chuck Short (zulcss)]

dx9s: Where did this deb come from?

Thanks
chuck

[dx9s (dx9s)]

From deb source (and I compiled it)
However I need to change the version number because an apt-get update/upgrade will upgrade to the latest version and you'll need to apt-get remove/purge the latest and install the older one.

Until I hear a better compelling reason to change the permissions/ownership (to how they suggest) "workaround" (aka all files on web server in question are to be owned by ROOT or the switched user account suPHP uses)... I'm used to a different ownership model when using suPHP.

Doesn't make sense because in order to make the parent folder owned by root.root the user/group/world -- the world permissions must be open to anybody on the system.. where I like to have the parent folders owned by the same person the apache httpd is running as... so ONLY people that are that user (or in a particular group) can even GET to the same folder... Having it world readable means you should NOW never allow shell access on the machine (because people can now go into the folder and read other's PHP scripts and pull things out like passwords or look for exploitable bugs).

I really dislike being told the new cold is more restrictive and requires a change in permission and after looking at the changes.. it's really less secure.

--Doug

----------------------------------------
> From: <email address hidden>
> To: <email address hidden>
> Date: Wed, 27 Aug 2008 14:24:43 +0000
> Subject: [Bug 253268] Re: php5-cgi not working with suphp in Hardy
>
> dx9s: Where did this deb come from?
>
> Thanks
> chuck
>
> --
> php5-cgi not working with suphp in Hardy
> https://bugs.launchpad.net/bugs/253268
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “php5” source package in Ubuntu: New
> Status in “suphp” source package in Ubuntu: New
> Status in “suphp” source package in Debian: New
>
> Bug description:
> Suphp doesn't work in Hardy. It seems that it is simply ignored and php processes are executed under www-data.
>
> It was working fine under Gutsy. I dist-upgraded a month ago but I discovered the problem only recently (because one of my website was unable to read a config file chmoded to 700). I'm pretty sure it's the dist-upgrade because the suphp log stopped the day I dist-upgraded (approximately at least).
>
> I didn't change anything in the config in the meantime. Also, when investigation the problem, I copied /etc/apache2 /etc/php5 and /etc/suphp from a working Debian installation. It doesn't work under Hardy.
>
>
> The symptoms are the following :
> 1) if mod_php5 is enabled, processes run with www-data permissions. phpinfo() returns "Apache 2.0 Handler " as the server API. (when suphp is working, it returns "Cgi/FastCgi" AFAIK
>
> 2) if mod_php5 is not enabled, you will receive an error 500. The logs contain the following lines :
> [Wed Jul 30 14:31:55 2008] [error] [client 212.190.219.18] SecurityException in Application.cpp:440: Handler not found in configuration
> [Wed Jul 30 14:31:55 2008] [error] [client 212.190.219.18] Caused by KeyNotFoundException in Configuration.cpp:234: Handler "application/x-httpd-php" not found
> [Wed Jul 30 14:31:55 2008] [error] [client 212.190.219....

[Russell Smith (mr-russ)]

Given there are upstream bugs, and a number of people discussing the bug. Is it safe to say this bug is confirmed rather than new?

[Micke Nordin (mikael.nordin)]

AFAICT this bug is still present in Jaunty. Unfortunatly I don't seem to be able to use the old deb-packages above in Jaunty as a work around (even though they seem to install fine with dpkg -i).

/Micke

[Piotr Kęplicz (keplicz)]

This problem can be fixed (at least in Jaunty) by changing "application/x-httpd-php" to "application/x-httpd-suphp" in {/etc/suphp/,/etc/apache2/mods-available/}suphp.conf. This solution was described in Debian bugreport #519005.

[Chuck Short (zulcss)]

This should be fixed in suphp.

Regards
chuck

[dx9s (dx9s)]

I know this isn't an issue with the distribution.. but a problem with the maintainer... Thanks Canonical for your support anyways.

It is just a little strange and I need to test what Piotr is referring to in Jaunty (I've been staying away from dist ugprades as the production machine I have requires each user to run their PHP code as their own user ID and upgrading means loss of server to those people [at the community college where I work] ).

--Doug

[Scott Nightingale (scott-conceptdigital)]

sorry if I'm a bit noob here but I'm running Ubuntu 8.04 LTS AMD64 so I can't use your i386 packages. Has anyone packed this up for 64bit or is there some other suggested method for resolving this bug? I tried the suggested method of changing application/x-httpd-php to application/x-httpd-suphp but continued to receive a 500 server error.

Cheers,

Scott

[Dave Walker (davewalker)]

This has been fixed since at least Lucid. Marking as such.

Thanks.