[pkg-lighttpd] Bug#600050: Bug#600050: /etc/lighttpd/conf-available/15-fastcgi-php.conf: fastcgi-php file missing a required directive

Olaf van der Spek olafvdspek at gmail.com
Thu Apr 7 17:17:02 UTC 2011


On Thu, Apr 7, 2011 at 5:24 PM, Arno Töll <debian at toell.net> wrote:
>> No.
>> It does increase the amount of code that's executed, but (IMO) not in
>> a significant way. FastCGI is not some obscure module.
>> If loading the module does affect safety in a significant way one
>> should probably avoid the entire webserver.
>
> Safety is the minimization of unwanted risks. This is, how an engineer
> defines safety. For security this reads: avoid unneeded threats whenever
> you can. The code you don't execute can't lead to a vulnerability.
> Especially if you execute it unnecessarily.
>
> It's as simple as that.

It's also, almost always, a tradeoff with usability / simplicity.

>> Ideally the module would unload itself when not configured.
>
> I'm unsure if a module should apply this kind of heuristics since I tend
> to state "software should not start to think on behalf of the
> administrator being too lazy to configure things".

If things can be automated without disadvantages then they should be automated.

>> I agree about those goals, so the question is: what is core functionality?
>
> Bear in mind we discuss about a web server, that is essential core
> functionality is well defined by HTTP 1.1
> [http://tools.ietf.org/html/rfc2616]. That means: Everything needed to
> run a fully compliant HTTP 1.1 web server is enough for the
> functionality /everyone/ expects when installing lighttpd.

That'd be the minimal functionality required. Debian aims for usable,
not necessarily minimal.

> For lighttpd this requires the core components only, that can't be
> loaded (or unloaded).
>
> Now let's take a look in the trunk's lighttpd.conf:
>
>>>server.modules = (
>>>        "mod_access",
>>>        "mod_alias",
>>>        "mod_compress",
>>>        "mod_redirect",
>>>#       "mod_rewrite",
>>>)
>
> As we are packaging for Debian we need to be conform to Debian's Policy
> Manual § 11.5
> [http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl].
> Following that we require an alias for /cgi-bin, /doc and /images, hence
> mod_alias is required (what happened to the DPM compatible configuration
> by the way, the current configuration looks like as if it would violate
> the DPM?)

It was moved to conf-available, as it interacted very badly with other
alias stuff.

> mod_access provides url.access-deny which is a good idea too, although
> this probably should include .htaccess as well, since a lot of people
> leave those files in their doc roots as well, even if they are useless
> for Lighttpd.
>
> mod_compress might be technically a good idea, but it is not required
> for core functionality. I would suggest not to remove it completely, but
> to comment it out and leave it as hint to the user.

Again, minimal vs best suited to majority.

> mod_redirect is not used at all in its default configuration currently.
>
> Note I also dislike to split up configuration into dozens of files, so I
> would suggest not to remove some basic configuration quirks, but to
> leave the administrator the choice whether he wants to activate a
> certain option (set) or ship alternative configuration files.
>
> (Note I also asked to join the pkg-lighttpd team earlier today through
> Alioth, since we are getting off topic here)

Eloy will have to handle that.

Olaf





More information about the pkg-lighttpd-maintainers mailing list