[php-maint] Bug#685340: Bug#685340: php5-common: provide one /etc/apache2/conf.d/php5.conf for all SAPIs

Mon Aug 20 20:07:22 UTC 2012

Hi Ondřej.

On Mon, 2012-08-20 at 13:18 +0200, Ondřej Surý wrote: 
> > - All SAPIs share the same config, thus no surprises.
> I am not sure it that's a good idea
okay,... why do you think so? :)

> (even when I drop your mix of
> AddType and SetHandler).
Well from Apache's view, all these are in the end more or less the
same... so whether you use handlers or mime types to mark the files is
IMHO largely a matter of personal taste.
I prefer MIME types,... you used handlers IIRC,... that's why some of my
examples use MIME types and some handlers =)

> I'll try to come with something else which
> doesn't involve installing apache configuration files when install
> php5-cli package.
Yeah,... I've though about that, too, and also don't like it in
principle.
Maybe one idea would be, that you install that file as a choice within
debconf.
It could even ask, for which webservers (if eventually more would be
supported) it should get installed.... any maybe also, whether it should
be globally enabled already or not.

> > - No longer the need for manually configuring Apache with respect to PHP when using CGI/FCGI
> That's simply not true.
Well I meant with respect to the mime types...

I guess you mean it's real activation... while it should still not get
into conflicting SAPIs, running at the same time.

I think it could work to get the full configuration out of the box, for
multiple SAPIs.
Of course I do not talk about the configuration of e.g. FPM itself. Just
what's needed to get the types and the interpretation on.

1) For mod_php,... does it _always_ expect a handler name of
"application/x-httpd-php" or can this be configured?
If not, we have to either patch this (if we'd have wanted one common
config file) or just stick with it.

2) Anyway, we simply ship some configuration that globally sets either
the mime types or handlers.

Now we'd need some means to determine which SAPIs are installed, and to
prevent that more than one are used.
On could perhaps get that with <IfDefine> (for CGI/FPM) and for mod_php,
we can continue to use <IfModule>.
Now that would of course mean, that we need to -Dsomething (for CGI
respectively FPM) on apache startup/restart... does this sound
acceptable to you?

> - And FPM doesn't work with libapache2-mod-fcgid at all and needs
> libapache2-mod-fastcgi from non-free, so again manual intervention is
> required.
Ah,.. I wasn't aware... :(

> > I personally, would strongly recommend AGAINST also having the Action/ScriptAlias directive there;
> > admins or package maintainers should place them in the <Directory> definitions where this
> > is needed.
> I agree on that, but from different reasons (as documented in
> README.Debian) - the php5-cgi is webserver agnostic and we don't want
> it to conflict with libapache2-mod-php5(filter).
Yeah,... we definitely should avoid that..

> Why? You keep pushing your opinions without giving any technical
> reason. Default Debian configuration is secure (it allows only files
> in /var/www to be accessed).
General principle: The less code/functionality is enabled, the less can
happen.
We can never think of all possible tricky attack vectors that might be
used... just consider that mod_php has some hole that's exploitable.
Maybe in conjunction with some other hole in a website, a user manages
to upload somehow his evil .php file and get's it executed.

Of course,... this can always happen; sure.
But when we enable PHP (or anything else like it) globally on the
webserver, the possible working surface for an attacker is automatically
much bigger.
Consider one would need PHP only in some vhost, that's anyway secured
with SSL client cert authentication.... so you have some trust to the
people that may get in at all.
But there are also vhosts that are open to the public.
If now, there's an attack vector like the above,... one may in practise
be safe if PHP was only enabled on the SSL secured vhost... but perhaps
not if enabled globally.

> You keep repeating this, but Apache manual says:
> http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext
> > If more than one extension is given that maps onto the same type of
> meta-information, then the one to the right will be used, except for
> languages and content encodings. For example, if .gif maps to the
> MIME-type image/gif and .html maps to the MIME-type text/html, then
> the file welcome.gif.html will be associated with the MIME-type
> text/html.
_IF_ (!!) more than one extension is given...
In other words: if we have test.php.foo ... and foo is not a mime-type
(or any other meta-information type)...

> Again you keep pushing Files vs FilesMatch, but did you do or see any
> performance tests.
Well it's just some educated guess ;) ... with FilesMatch you have
PCRE,... therefore always need to jump to that's libraries code and
compile a more complicated regexp language.

> I would guess that processing the PHP file in most
> common scenarios would be much longer than the performance hit induced
> by using FilesMatch.
Yeah of course... :)

Anyway... is I've already commented on d-d,... the current approach
seems to be secure and ok. :)

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/20120820/ee65f0f3/attachment.bin>