httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject execution API and UID issues for logs etc.
Date Sun, 05 Jan 1997 20:08:48 GMT

Somewhat of a distraction here, but this seems to be the topic du jour.

Comments regarding the "suexec API" have prompted more thought about
what a "real API" might offer. These issues apply to many more parts
of the server operation than just exec() as evidenced by the logfile
discussion. Perhaps we need to think about a way to include these
changes in the module API in general. These comments apply to 2.0
and beyond.

UID concerns:

* logfiles
* access control for modules like mod_perl and mod_php (ie DBMS, Mail)
* execution of CGI and other external programs
* filesystem security from other users


The following thoughts occur to me as a solution to much of this.

Perhaps we need to start thinking about a "building block" approach
to the server and it's communication with it's children.


Main Server - Starts as root, setuid to safe user
It's jobs are:
	Exec() "lead" processes for <VHost> as the configured User/Group.
	Log access info for <VHost> requests.
	Monitor nameservice for each <VHost>?
	It essentially becomes a logging process.
	Proxy?
	
<VHost> Servers - Started as configured User/Group
Their jobs are:
	child management growth and shrinkage
	could provide logs permiting access by the User/Group
	file access would only require User/Group permissions (not world)
	access to databases, CGI, Mail, etc as the User/Group
	

It occurs to me that we are very close to this through use of <Listen>.
The problem (as I see it) is a main logging process and passing the
responsibility of pre-forking children to the subprocesses or parents
of the <VHosts>. This also doesn't really address the ~user thing very
well, but I have always thought that was a bit messy anyway.

Could someone comment on how this would work in a threaded server?




Mime
View raw message