suexec for directories

[Ben Charlton <B....@kent.ac.uk>]

I'm currently involved in building a new webserver environment to
replace a 6 year old server running a large website with a fairly broken
publishing model.

One of the things we'd like to do is lock down PHP so that we're no
longer using mod_php running all as one user, and this means using
cgi mode under suexec. The kicker is that we can't use a separate vhost
for each department/publishing group for various political reasons.

Naturally, the suexec documentation says "do not edit this on pain of
death", etc, but we don't seem to have any choice if we want to support
suexec configuration local to the <directory> stanza. I can understand
why only virtualhosts were supported under 1.3, as suexec seems to be a
massive hack that co-opts the User and Group directives, but mod_suexec
under apache 2.2 seems much cleaner.

What I would like to know is, a) is there a big obvious answer to this
that I'm missing, and b) does the following diff for mod_suexec.c open
up subtle and terrifying security holes that we've managed to overlook?


63c63
<     const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE|NOT_IN_LIMIT);
---
>     const char *err = ap_check_cmd_context(cmd, NOT_IN_LIMIT);

118c118
<     AP_INIT_TAKE2("SuexecUserGroup", set_suexec_ugid, NULL, RSRC_CONF,
---

>     AP_INIT_TAKE2("SuexecUserGroup", set_suexec_ugid, NULL, RSRC_CONF|ACCESS_CONF,


Many thanks,
Ben 

Re: suexec for directories

[Bart van der Schans <sc...@hippo.nl>]

Ben Charlton wrote:
> I'm currently involved in building a new webserver environment to
> replace a 6 year old server running a large website with a fairly broken
> publishing model.
> 
> One of the things we'd like to do is lock down PHP so that we're no
> longer using mod_php running all as one user, and this means using
> cgi mode under suexec. The kicker is that we can't use a separate vhost
> for each department/publishing group for various political reasons.
> 
> Naturally, the suexec documentation says "do not edit this on pain of
> death", etc, but we don't seem to have any choice if we want to support
> suexec configuration local to the <directory> stanza. I can understand
> why only virtualhosts were supported under 1.3, as suexec seems to be a
> massive hack that co-opts the User and Group directives, but mod_suexec
> under apache 2.2 seems much cleaner.
> 
> What I would like to know is, a) is there a big obvious answer to this
> that I'm missing, and b) does the following diff for mod_suexec.c open
> up subtle and terrifying security holes that we've managed to overlook?
Did you have a look at mod_suphp? http://www.suphp.org/Home.html

Regards,
Bart

> 
> 
> 63c63
> <     const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE|NOT_IN_LIMIT);
> ---
>>     const char *err = ap_check_cmd_context(cmd, NOT_IN_LIMIT);
> 
> 118c118
> <     AP_INIT_TAKE2("SuexecUserGroup", set_suexec_ugid, NULL, RSRC_CONF,
> ---
> 
>>     AP_INIT_TAKE2("SuexecUserGroup", set_suexec_ugid, NULL, RSRC_CONF|ACCESS_CONF,
> 
> 
> Many thanks,
> Ben 


-- 

Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-------------------------------------------------------------
schans@hippo.nl / http://www.hippo.nl
--------------------------------------------------------------

Re: suexec for directories

[Graham Leggett <mi...@sharp.fm>]

On Tue, September 12, 2006 5:26 pm, Ben Charlton wrote:

> One of the things we'd like to do is lock down PHP so that we're no
> longer using mod_php running all as one user, and this means using
> cgi mode under suexec. The kicker is that we can't use a separate vhost
> for each department/publishing group for various political reasons.

You could use a single vhost per department/publishing group on a private
localhost webserver install (or multiple private localhost installs), and
then "switch in" each vhost into your mail website wherever it needs to
live using ProxyPass and mod_proxy_http.

You would only need do this for departments actually using php, which in
theory wouldn't be the default, and your departments will not even see
this is happening.

Regards,
Graham
--