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

[Christoph Anton Mitterer]

On Mon, 2012-09-17 at 20:48 +0200, Matthias Urlichs wrote:
> > 2) Ondrej, I've already planned to suggest you... to change the
> > _handler_ name "application/x-httpd-php" that we now use throughout the
> > packages to someting like "php-script"...
> > It easily confuses people that this would be a MIME type,... while it is
> > actually a handler.
> Ah. Thank you, that was in fcat one of the problems I struggled with.



> > In principle we tried to explain in the NEWS file what has happened,...
> > obviously we cannot cover _any_ possible setup where this could occur
> > somehow; there are simply way too much possible and complex
> > configurations 
> There are also a couple of simple configurations which get broken. They
> should not be.
Which?


I mean my personal goal (though beware that I'm just some idiot
considering himself being smart ;-) ... and in not a member of Debian's
PHP team) would be about the following:

- ideally all PHP SAPIs (including the different flavours of FastCGI,
that is either mod_fcgid ord mod_fastcgid), should be able to work on
the same systems (of course each interpreting differen files).

- the PHP packages should configure so much out of the box, that
everything with respect to file-extensions, handlers and that like is
there (in a secure way)... but NOT activated.

- either the user should activate PHP himself (server-wide, vhost-wide,
or per directory context)
or
the programs/packages using PHP should do so for their
default-out-of-the-box config.

- ideally, the user could then always select which SAPI is to be used

- ideally, things would default to either CGI or some FastCGId with
doing user privilege separation (i.e. not everythign running as
www-data); I put my self a lot of effort into this, to make PNP4Nagios,
Icinga-CGI, Icinga-WEB and Nagios-CGI running... all with different
users,... all with clean user based DB authentication.
It's a pain to find out how to do this, but once done, things are
actually easy and I would like to see all users benefit from this
eventually.


I'm not sure whether this is also what Ondrej and his team colleagues
have in mind, but if so, we will sooner or later anyway face the step
where existing setups might break.

PHP/Apache is mighty things and one cannot expect it to work
reasonably/securely if one has no idea on what happens.

I personally would rather vote for not all things working in a Apple™
out-of-the-box-but-perhaps-insecure style.


So what I mean in the end: We cannot take all responsibility away from
the admins, nor should we.



> Conceptually, setting up a mod_fastcgi server with separate users is rather
> simple:
Off topic: 
With either of both (mod_fastcgi/fcgid)... can you really specify users
per <Directory>-context?




> In fact, this should not happen regardless of whether such re-enabling
> breaks anything. It might even introduce a security hole; imagine
> re-enabling mod_dirindex.  :-(
AFAIU, it doesn't really enable anything... it just sets a different
handler, which may take away handling from what you've set up.


Which leads me to the question, what happens when a file is accessed
which has a handler that doesn't exist?
That may even cause security issues then...


> Therefore I recommend that, at minimum, an upgrade MAY NOT re-enable
> an Apache module which the administrator has specifically disabled.
As said above, we don't do this anyway.... there is not even a php5_cgi
_module_... this is just a trick ;)


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5450 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20120917/96ca4a1b/attachment-0004.bin>