Mass Vhosting SuExec (was Re: [PATCH] remove hardcoding of suexec log location)

[Thom May <th...@planetarytramp.net>]

* Aaron Bannert (aaron@clove.org) 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.
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. 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 :-)
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.
Cheers,
-Thom

Re: Mass Vhosting SuExec (was Re: [PATCH] remove hardcoding of suexec log location)

[Thom May <th...@planetarytramp.net>]

* Colm MacCárthaigh (colmmacc@Redbrick.DCU.IE) wrote :
> On Wed, Jan 01, 2003 at 10:43:18PM +0000, Thom May wrote:
> > * Aaron Bannert (aaron@clove.org) 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 
> unneccessary!
> 
I'd specifically disagree with you there. Virtually every SA at any ISP i've
spoken to plus numerous webhosts, including the one I work at, has patches
on suexec.

> > 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. 
> 
You're answering specific points, not solving the major problem. Whether or
not /home is a good docroot is not the question I was asking, i was using it
as an example.
 
> In general for sites with virtual hosts that need SuexecUserGroup
> I set docroot to $prefix/vhosts, and put them all in there, problem
> solved :)
Wonderful when setting up a new system from scratch, not so useful for
legacy systems and places that already have multiple machines run this way.

> 
> > 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 ?

Adding vhost and restarting apache.

> 
> 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
It's already having to read SuexecUserGroup; why not use SuexecDocroot where
necessary as well? (yes, it's duplication of data, but it wouldn't
necessarily be used for every vhost that was setting a SuexecUserGroup
anyway)

> an awful lot of work for something that's exec'd for every CGI
> and is security critical.
> 
Agreed, but in a lot of cases suexec is being run with reduced security to
work round this problem anyway.
> 
> > 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 ?
> 
Tony points out one methodology for this, I'm sure there are others.
Cheers,
-Thom

Re: Mass Vhosting SuExec (was Re: [PATCH] remove hardcoding of suexec log location)

[Tony Finch <do...@dotat.at>]

On Thu, Jan 02, 2003 at 01:23:07AM +0000, Colm MacCárthaigh wrote:
> 
> suexec will never "work correctly" with vhost_alias, or mod_rewrite :)
> How would you tell it what username/group to use ?

The approach used where I developed mod_vhost_alias was to get them from
the ownership of the script that is to be run.

Tony.
-- 
f.a.n.finch  <do...@dotat.at>  http://dotat.at/
NORTH FORELAND TO SELSEY BILL: SOUTH 4 INCREASING SOUTHWEST 6 OR 7 THEN EASE 5
OR 6 BEFORE VEERING NORTHWEST 6 TO GALE 8. EASE LATER SOUTHWEST 5 OR 6.
OUTBREAKS OF RAIN, HEAVY AND PERSISTENT AT TIMES. MODERATE. MODERATE TO ROUGH.

Re: Mass Vhosting SuExec (was Re: [PATCH] remove hardcoding of suexec log location)

[Colm MacCárthaigh <co...@Redbrick.DCU.IE>]

On Wed, Jan 01, 2003 at 10:43:18PM +0000, Thom May wrote:
> * Aaron Bannert (aaron@clove.org) 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 
unneccessary!

> 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:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9038

for one.

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

http://redbrick.dcu.ie/~colmmacc/patches/proc.patch

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. 

-- 
colmmacc@redbrick.dcu.ie        PubKey: colmmacc+pgp@redbrick.dcu.ie  
Web:                                 http://devnull.redbrick.dcu.ie/