httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCárthaigh <colmm...@Redbrick.DCU.IE>
Subject Re: Mass Vhosting SuExec (was Re: [PATCH] remove hardcoding of suexec log location)
Date Thu, 02 Jan 2003 01:23:07 GMT
On Wed, Jan 01, 2003 at 10:43:18PM +0000, Thom May wrote:
> * Aaron Bannert ( wrote :
> > The log is generated from the suexec binary, not httpd, right?
> > Then we can't use a directive to control it and it needs to be
> > hardcoded for safety.
> The other issue for suexec is mass vhosting; this has somewhat different
> needs, and mostly results in ISPs patching suexec to do what they need,
> which seems like a bad thing unless the ISPs can sucessfully audit the
> resulting codebase.

It's a very bad thing, because in 99.99% of cases it's completely 

> The real problem is that mass vhosting generates large numbers of document
> roots; covering them all with one docroot compiled into suexec can result
> in, eg, /home being set as the docroot.

/home is a very bad docroot, and I'd question the reasons behind
hosting virtual hosts in /home, the usual reason is for FTP/shell
access, but that can be solved with symlinks, or just setting
the homedir elsewhere. 

In general for sites with virtual hosts that need SuexecUserGroup
I set docroot to $prefix/vhosts, and put them all in there, problem
solved :)

> Compiling with a list of document roots sounds good in principal, but 
> we on average add a site an hour, recompiling suexec every hour 
> isn't particularily practical, and the
> configure args would be several miles long :-)

Every hour! Youch, but are you adding a VirtualHost and restarting
apache every hour ? If not, how are you mapping those URI's and
how are you associating them with a username/group ?

If you are, and if this is common, there is some limited justification
for getting suexec to support such situations. But against that is
the reality that in order to support it suexec would have to parse
every single configuration file, determine which VirtualHost blocks
have SuexecUserGroup directives and remember their Docroot, that's
an awful lot of work for something that's exec'd for every CGI
and is security critical.

As has been pointed out, if people really want to use /home, then
mod_rewrite [+mod_proxy +mod_userdir] is probably a much better 
way to go.

> It seems to me that a different binary would be the best path;
> suexec-mass-vhost or whatever. it needs to be able to work correctly with
> mod_vhost_alias, and it potentially needs to be able to take docroot
> arguments from httpd.conf.

suexec will never "work correctly" with vhost_alias, or mod_rewrite :)
How would you tell it what username/group to use ?

The whole point of these approaches to virtual hosting is to simplify
a long list of domains into one ruleset. That's not compatible with
having a different username/group for each one. Then again, if you
wanted to have them all run as the same user, there've been (now
incomplete) patches to allow SuexecUserGroup to work in <Directory>
blocks, see:

for one.

Aswell as the mass vhost stuff there's still the outstanding issue 
of making SHELLCMD work with suexec , see:

from the STATUS. Also maybe change the default 
permissions of the suexec binary to 4750 and
advise people to chgrp it to the group httpd
runs as. 

--        PubKey:  

View raw message