On Thu, Jul 19, 2012 at 05:26:23PM +0100, Nick Kew wrote:
> Does it run per-dir config as root?
Yes, although it has very limited root rights; it can setuid and it can
read arbitrary files and directories, but it cannot e.g. load kernel modules
or write to arbitrary files.
> How does it protect against such potential attacks as running an
> external program as root through a RewriteMap running earlier
> than the directory walk?
If the administrator (who will naturally be root) sets up such a RewriteMap,
it will naturally be executed as (limited) root. RewriteMap is not supported
in .htaccess.
Note that this is very much comparable to mod_privileges, for both cases.
With seccomp v2 support (coming in Linux 3.5), we can also restrict the uid
ranges to setuid to.
> Given that the header_parser runs immediately after directory
> config in request.c, are there specific reasons (beyond inelegance)
> not to run as header_parser with REALLY_FIRST?
As far as I understand, we don't have the per-directory configuration merged
at that stage. Supporting separate vhosts in a more fine-grained fashion
than <VirtualHost> was a common request (we now support <Directory> and
<Location>, and I'm looking at integrating ap_expr support for 2.4).
> Dropping the connection gratuitously breaks HTTP, and so has no
> place in httpd (of course, a third-party module sets its own rules).
On the contrary, RFC 2616 explicitly allows this behavior; section 8.1.4
states “A client, server, or proxy MAY close the transport connection at any
time. [...] This means that clients, servers, and proxies MUST be able to
recover from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests without
user interaction so long as the request sequence is idempotent (see section
9.1.2).”
All clients that I know of deal with this without any problems; the only
problem I've ever seen is with old versions of Varnish, and that has long
since been fixed as a bug in Varnish.
> Would it need a core patch to return an Internal Server Error (500)?
Without any patches, it will return 403. In any case, 500 or other HTTP error
messages are not very useful; it breaks several useful use cases, such as
a) A user browsing to vhost-with-uid-1001, and then before the timeout
follows a link to vhost-with-uid-1002.
b) vhost-with-uid-1001 includes an image (or other media) from
vhost-with-uid-1002.
c) A proxy (reverse or otherwise) or web crawler needs to access
vhost-with-uid-1001 and vhost-with-uid-1002 in quick succession
(similar to a) ).
These are not hypothetical situations; clients actually do this, and they
will return hard errors to the user if they are presented with HTTP error
messages.
/* Steinar */
--
Homepage: http://www.sesse.net/
