httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: doc patches for symlinked logfile warnings
Date Sun, 05 Jan 1997 18:20:12 GMT
On Sun, 5 Jan 1997, Jim Jagielski wrote:

> My point is that Apache already allows for cgi-scripts to be run. In
> doing so, we "allow" for wrappers if the webmaster so desires but
> we also "allow" for them to be totally braindead as well. To me,
> this seems all that Apache should really be worrying about. Once we
> start focusing on also providing "secure" ways of doing scripts, we
> are biting off more than required by a server. 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 it is more secure overall to have one secure solution that provides
all many people need, and if they want more they use something else than
it is to have a million solutions, some of which are secure but may of
which aren't; and the average user has no way to figure out what is what.

> I think the only thing Apache really should be worried about _is_
> the API. One good reason of course is that it _does_ shift the
> blame, but another is that it allows for 3rd parties who might
> be much more up-to-speed to fill the gap.

And 3rd parties that may be far less up-to-speed.  While I still encourage
the idea of others making wrappers that suit them, I think there will be a
lot more bad 3rd party attempts if apache doesn't ship something which is
viewed as half-decent.

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

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. 

We aren't getting any further on what to do for 1.2.  I don't know how
anyone could advocate releasing suexec as is, mainly due to the userdir
problems.  One thing which would help a lot is a better way for suexec to
know it is called by Apache, but I don't think that will happen for 1.2.
Another solution is for Apache to know what is really CGI space and what
should be run as a CGI and what shouldn't.  I like that idea if it can be
done without bloat, but no one else seems to.  Another option is to hack
suexec for 1.2 to only allow ~user/public_html/ or
~user/public_html/cgi-bin requests.


Mime
View raw message