httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Hess <>
Subject Re: I'm changing my mind about config modules
Date Mon, 17 Apr 2000 15:43:40 GMT
On Fri, Apr 14, 2000 at 12:00:05PM -0700, Greg Stein wrote:
> But the nasty part, and a big reason why we punted at this time, is
> getting that tree changed. Consider the fact that Apache has multiple
> processes. When a client connects and requests a change to the tree, it
> is to one of the child. That change must be propagated to the parent
> process, the change takes place, then the parent must fork a new set of
> children.
> Given the re-fork, you're basically talking about a graceful restart. At
> that point, you may as well decide to just punt the whole dynamic config
> and go back to re-reading a (changed) config file.

Having the child propagate config changes to the parent may open security
holes (because the child runs as nobody and the parent runs as root).
Having the child write a new config file _definitely_ will open security
holes (because the config file has to be writable by children, so almost
any security hole allows exploits that rewrite the config - also, the
child would probably need to be able to signal the parent).

What's fundamentally wrong with seperating the config stuff into a
seperate server?  That can address both of those problems, because the
config server can have different permissions and availability than the
primary server.  Perhaps that can even be worked into a single server,
somehow, with the primary parent spawning seperate config children which
don't listen on the same ports or run with the same permissions.


View raw message