httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason A. Dour" <>
Subject Apache Process Model (or Dean Makes My Brain Hurt!)
Date Mon, 13 Oct 1997 14:22:18 GMT

URGH!  Dean make Mongo brain hurt!  Mongo not want to think this much so
early on Monday morning.  ;)

On Sun, 12 Oct 1997, Dean Gaudet dropped these nuggets of wisdom:
> I don't know if anyone else realised it, but this is the basis of a much
> more secure apache.  i.e. an apache that needs root for almost nothing.
> Tell me if I've forgotten anything here:

	Wow.  Ummm, I think all this is a good step towards a revision of
the server process, but I do have one question...  Did you mean this to be
1.X or 2.X?  I'm hoping 2.X, since there were going to be major changes to
the architecture anyway (or there is likely to be, right?), and we could
work on issues such as the ones you've raised.

	The work looks interesting, and if we're doing major revisions to
the server process, I'm going to be extremely interested in such because
of suEXEC and how to *get rid* of it.  So I'm going be noisy for a change
and toss in my two bits worth even if I am less of an Apache Guru(tm) than
most of you other guys.  8)

	As you probably know, suEXEC is *not* the panacea of CGI security,
and I never intended it to be such from the first day I started coding on
its predecessors.  I still believe that such UID swapping should occur in
such a way that it is closely integrated into the server at some level.
Setting the current server process model as root is scary, so suEXEC was a
necessary evil.  However, if we're breaking the server into more secure
sections, CGI security can be brought into the fold and suEXEC can be

	Also, if we're careful with our new server process model, we can
provide *private logging* for those who want it.  I can't tell you how
many users I've had frustrated (me included) by having to grep private log
entries from dozens of megs of logs.  This is not an unachievable goal,
IMHO, to provide the following types of logging: System, VHost, and User.

	Thus, I like your "Apache Supervisor" idea, with a few changes to
suit my Special Interests.  8)  Just make sure I don't forget anything
necessary...OK?  8)

	ApacheSuper (root:root)
		* open Listen sockets
		* fork()
			- priv to ApacheLogger UID/GID
			- exec ApacheLogger
		* fork()
			- priv to UID/GID of serviced request
			- exec ApacheServer with proper args
		* ApacheSuper loop:
			- monitor for requests
			- monitor ApacheLogger
			- monitor ApacheServer children

	ApacheLogger (wwwlog:wwwlog)
		* open logging pipes
		* write log entries to SYSTEM log files

	ApacheServer (UID and GID varies with request)
		* do Request Magic(tm)  (GEE, I'M SO TECHNICAL!)
		* log to ApacheLogger pipe
		* log to VHOST/USER log if desired

	Now, problems I can see right off despite my lack of experience
with our current process model:

	* ApacheServer is still going to be a large binary, so running
		and exiting this is a Bad Thing.  Some kind of talk would
		need to be set up between ApacheSuper and ApacheServer
		processes that stick around.  Is our current method of
		process communication viable?
	* ApacheLogger has verification problems similar to the ver.
		problems we're presently having with suEXEC.
	* Are we still heading into a Threaded Future?  If so, then is
		all of this conjecture for aught?

I'm sure there are more, but my brain hurts.  I need to go do something
mindless, like installing a new NT server...

# Jason A. Dour <>                            1101
# Programmer Analyst II; Department of Radiation Oncology; Univ. of Lou.
# Finger for URLs, PGP public key, geek code, PJ Harvey info, et cetera.

Version: 2.6.2


View raw message