Message-Id: <199607101522.KAA14911@sierra.zyzzyva.com>
To: new-httpd@hyperreal.com
Subject: Re: Oops explained 
In-reply-to: ben's message of Wed, 10 Jul 1996 15:09:53 +0100.
         <9607101509.aa12089@gonzo.ben.algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 10 Jul 1996 10:22:14 -0500
From: Randy Terbush <randy@zyzzyva.com>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

> > This is a safety net that I had planned to add to the http_exec.c and
> > setuid exec stuff that Jason and I have been working on. It would
> > then set these limits for included execs, cgi execs etc.
> 
> Fine, but I want it _now_!

:-) That's a nice change.

> Presumably http_exec is just a distillation of various bits of exec code from
> about the place? If so, can we move over to it before the setuid exec is
> complete?

Yes. An expansion of can_exec() and a do_exec() function to replace
calls to exec() throughout the server.

> As a matter of interest, what technique are you using in the end to soothe our
> security fears?

Jason has been doing some work on the code to hopefully support UserDir
setuid and has been making some changes to the wrapper. I'm currently
running a version that masks the CWD with a compiled in DocumentRoot.
This at least forces execution only of files in the webspace and only
for files whois owner matches the directory owner.

I'm sure that Jason will have some other things to add to this, and
I prefer not to start that security debate all over again (yet). I think
that Jason plans to have the per/UserDir stuff ready for presentation
any day now. It would be relatively easy to provide a patch to centralize
the exec code without enabling the wrapper aspect.