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.
smime.p7s
Description: S/MIME cryptographic signature
