httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kosek <>
Subject Re: Dispatching MPM
Date Tue, 19 Jul 2005 13:07:40 GMT
On Tue, Jul 19, 2005 at 11:14:51AM +0100, Nick Kew wrote:
> > In presented example, client1 has specified Host: header and has been
> > redirected to worker1, while client2 hasn't specified it yet, so it is
> > still connected to the dispatcher.  The diagram is created with
> > assumption that socket passing will be used, not proxying.
> That is how 1.x and its successors work, isn't it?

No, diagram shows how D-MPM should work (other MPMs don't have anything
like dispatcher).  But if we decide to make dispatcher act as proxy (and
we probably must, if we want connection level filters work), clients
won't ever be connected to worker directly, but through dispatcher.

> >   Most existing solutions (that separate different virtual hosts) have
> >   the architecture where many threads/processes (each running with
> >   privilege of some virtual host) accept connections, and redirect them
> >   if client wants another virtual host. This may create potential
> >   security problem--if there were an exploitable bug in code before
> >   redirection, an attacker would have a possibility to gain privilege
> >   of user of any virtual host.
> I'm not quite sure what you're saying.  What existing solution do
> you have in mind that is open to a transfer-of-privileges attack?
> Surely not the standard MPMs and suexec?

I compare design of D-MPM to design of perchild, Metux and peruser, ie.
other MPMs that aim for separating privileges of different virtual
hosts.  With D-MPM, some code will be executed with dispatcher's
permissions, and rest with permissions of appropriate worker.
Only spawning new children must be done by master apache process (with
root privileges), but it would be a small piece of code...

> >	 In D-MPM, an attacker would gain only
> >   dispatcher's permissions, which can be very restricted.
> Agreed.  A minimal dispatcher sounds great.  You should probably
> aim to have it require chrooting, as well as running as a user with
> no shell or login (perhaps drop those constraints under #ifdef DEBUG).

Of course, that's why I put /var/empty as dispatcher's root directory in
the example.

> >   To allow to utilize any of security extensions particular system has,
> >   D-MPM will have a loadable module support. Making D-MPM change some
> >   non-standard permissions would involve only writing a small shared
> >   library, without need for changing D-MPM's source or even recompiling
> >   it.
> Do you mean it will implement a new optional hook specifically for
> chroot-like operations?

Yes, exactly.

> That sound very nice: maybe just make my
> "insist on chroot" suggestion the default if no module does
> something else.


> >     Workers won't change much, so code from existing MPMs should be
> >     somehow reused.  Even running different workers for different
> >     virtual hosts should be possible.  So I'm thinking of possibility of
> >     some generic code reuse, that would allow me to use workers from
> >     almost any MPM (prefork, worker, event...).
> Agreed.  For the time being, maybe just take the preforked processes.
> That'll mean you get to satisfy the PHP crowd.  Of course if you can
> harness Worker/Event/Other for no additional work, that would be the
> icing on the cake:-)

Prefork looks like a good place to start, as its the simplest of
existing stable MPMs...

> >     Logging.  Currently every worker has descriptors of every log file.
> >     To provide security, after creating a worker and changing its
> >     permissions all the unnecessary log file descriptors will be closed.
> Since a worker process only ever serves one vhost in this architecture,
> it'll only ever need a single server_rec.  For security, it shouldn't
> even see the server_recs for other vhosts.  A single server_rec has
> a single logfile descriptor open.

I actually want to have worker for each set of permissions (there may
be more vhosts with the same permissions).  It would have descriptors of
log files of all vhosts it serves, but as all of them have the same
owner, group, etc. it won't cause security problems.


View raw message