httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ras...@bellglobal.com
Subject Re: wrappers for things other than cgi...
Date Mon, 24 Mar 1997 21:17:13 GMT
> Just curious if there'd been any talk of expanding the notion of user/group
> setuid "wrappers" around...
> 
>  - SSI: exec, include, and cgi (does it already do this?)
>  - mod_php: database, file functions, exec

I have battled with this notion quite a bit.  I do not think it is 
technically feasible to setuid the httpd process itself.  Not only would
it need to run as root, but you can't setuid back to root on some OS'es and
looking ahead to a threaded Apache I doubt any OS other than Linux can run
individual threads as different user id's.

I think a workable solution for SSI and mod_php file related functions is to
only allow the operation if the owner of the file in question is the same
as the owner of the .HTML file the request came from.

For example, currently one could put the tag:

   <?include "/etc/passwd">

in a .HTML file and as long as the /etc/passwd file was readable by the
httpd user it would show up.

With this "wrapper" idea, the include would fail unless the owner of the
requesting .HTML file matched the owner of /etc/passwd.

One large caveat is that since the httpd process is still running as user
nobody, any files created by the httpd process will be owned by 'nobody'
and this wrapper would then prevent someone from reading a file they just
created.  I am not sure what the best way around that would be.

The way I am currently handling mod_php security is to run separate instances
of httpd as unique user id's for each virtual domain that needs mod_php
access.  This is the Netscape model of virtual domains and it works nicely.

-Rasmus

Mime
View raw message