httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: suexec concerns
Date Sat, 04 Jan 1997 05:20:21 GMT

> Hang on.  The parent httpd, normally running as root, knows for sure who
> its children are.  All we need is a way for suexec to ask the parent if
> process x is a child of the parent or not.  Part of that could be already
> implemented in the scoreboard stuff.  Comments? 

I tried to find a way to trace the "lineage" of a process for this
very reason. While I *think* it would be possible to do this by
mucking through kvm, I can't imagine how to make someting like this
portable. If you could come up with something, this would be golden.

> > On Fri, 3 Jan 1997, Randy Terbush wrote:
> > > * tack user-cgi directory onto the ~user path.
> > 
> > 	-1.  I *still* think we need to find a solution that does not
> > pre-compile the location.  If we don't we'll break SSIs even more than we
> > have already...and what of Dir/Loc/File?  I think we should push this to
> > 2.0.
> I think we need a solution that doesn't hardcode it, but if we don't have
> one before 1.2 we NEED to force requests to the user's web space.  Heck,
> even forcing them to ~user/public_html would work.  The security holes if
> this isn't done are just too gaping.

Since this is something that could easily be turned off when building
a wrapper, I see no reason not to distribute a wrapper that handles
this problem. After playing around with this a bit, I am convinced
that it is enough of a problem to disallow ~user in my wrappers.

> [...]
> > 	We need to move carefully on some of these issues...  I don't want
> > what is -- at present -- a decently functional suEXEC to become munged
> > pre-1.2 roll-out due to new "features."  If its more than a bugfix, I vote
> > for 2.0.
> Agreed.  However, remember that although it is functional right now it has
> security holes big enough to drive a whole flock of netscape servers
> through... and that's pretty big.
> If we can't fix them before 1.2, pull it from the 1.2 release and release
> it separately after 1.2.

This is a huge hole. It must be closed.

View raw message