httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: doc patches for symlinked logfile warnings
Date Mon, 06 Jan 1997 17:23:04 GMT
Marc Slemko wrote:
> 
> On Sun, 5 Jan 1997, Jim Jagielski wrote:
> 
> > It also opens us up
> > to nasty CERT notices, which can't be good. Right now, if some
> > uses the wrapper 'wideopen' with Apache, and 'wideopen' has a nasty
> > bug, it's the wrapper that gets the ticket, not Apache.
> 
> I don't care who the bug is blamed on; if it is there, it is there. 

I think that most members of the Apache group would be upset we
rec'd a nasty CERT notice not because of Apache itself, but for
a wrapper that's in the ./support section of the code. If we
provide a wrapper, it _better_ be secure or we better NOT
provide it.

> > Think of the wrapper as a module almost... we provide the API for
> > modules, but we don't write modules for every situation. If we want
> > to include a wrapper as unsupported, well, but like it or not,
> > suexec is seen as the "official" way to wrap cgi-scripts. I think
> > our responsibility should be to focus on an API primarily.
> 
> If you use that analogy, consider that providing an API and saying "Apache
> allows for execution of CGIs as users" without providing a program that
> interacts with the API is like saying "Apache can polish your shoes for
> you" without providing mod_polish; after all, we provide the API for it.

That's a stretch. First of all, I NEVER said that Apache provides for
execution of CGIs as users. Just that it provides for CGI execution.
Does the server _really_ have to concern itself with providing even more?
It's cool if it does, but it's not a requirement. What an API does it
provide a nice interface/method between Apache and modules. We MUST
come up with a valid wrapper API first _before_ we start creating one,
especially if we want to be smart about it and allow for other wrappers
to be used.

> 
> If we are not willing to make suexec secure, I don't think it should be
> included in any way other than (perhaps) an unsupported directory with a
> note saying it isn't secure but, hey, fixing the problems isn't easy so
> too bad. 
> 

I agree 100%. Well, not about the "too bad" part. It's just that if
we provide suexec, it must be 100% secure, even if it is very limited.
I think Jason and Randy did a good job and I think Mark's comments
are right on the ball about making things secure. I think an API
is a Good Idea right now.

-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"

Mime
View raw message