[php-maint] Bug#687418: Updating php5 to 5.4.4-5 broke FastCGI setup on my machine

Konstantin Khomoutov flatworm at users.sourceforge.net
Tue Sep 18 01:47:45 UTC 2012


On Mon, Sep 17, 2012 at 11:30:46PM +0200, Christoph Anton Mitterer wrote:

[...]
> Questions for those who are affected by this bug:
> 1) So you have both, php5-cgi AND libapache2-mod-fcgid installed, right?
Yes.

> 2) Then what happens is, the Handler from php5_cgi.conf overrides the
> way (whatever you did) to get .php files interpreted, right?
Yes, but not that straightforward: libapache2-mod-fcgid's configuration
file only installs this snippet:

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 20
</IfModule>

Obviously, at this point there's no conflict with php5_cgi.conf settings
yet.

So to get it interpret PHP scripts one needs to provide another
directory.  Personally, I read a couple of random HOWTOs on the topic,
and all they happened to suggest adding

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .php
  FcgidWrapperScript /usr/bin/php5-cgi .php
</IfModule>

with minor variations, so I did this.

Now the newly introduced settings from php5_cgi.conf override this
snippet (if it's placed in a file under /etc/apache2/conf.d -- dunno if
that matters or not).

And now I'm a bit lost as
1) You have clearly demonstrated the snippet like the one I used
   to enable FastCGI for PHP scripts is broken security-wise anyway
   (I dunno why -- never thought it could try to interpret .php.jpeg!);
2) Looks like changing the handler for PHP files (to fcgid-script)
   in the newly provided snippet in php5_cgi.conf is the right
   thing anyway to setup FastCGI for PHP so I don't really see a
   conflict there, it just has to be properly documented somewhere --
   in the libapache2-mod-fcgid docs supposedly, probably with
   appropriate hints in php5-common (or whatever).

> 3) Obviously, .php files are then neither interpreted by "normal" CGI,
> as Action directives are missing (and perhaps ScriptAlias and other
> things), right?
Seems to be the case.

> So we definitely get broken services (which by itself may cause security
> issues - but no one could really ever cannot cover these kinds of
> issues).
> Big problem though is, are the files then served as normal files by
> Apache?
Yes.
In my case, Apache did not set any Content-type HTTP header field for
these files when serving them (checked using the Live HTTP Headers
extensions for FireFox).

I'm not sure, but may be it's possible to not only set a handler for PHP
script files, but also provide some "null" implementation for this
handler by default?

Something like

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

AddHandler application/x-httpd-php null

>From [1], I gather it's not really possible, but I'm not an expert in
this field.

1. http://httpd.apache.org/docs/2.2/handler.html



More information about the pkg-php-maint mailing list