On Thu, 6 Sep 2001, Gilles Detillieux wrote: > getting users to rewrite a few wrapper scripts, I don't have a problem > with just yanking this rug out from under them. (Boy, am I mixing my > metaphors or what?) But if some other unforseen things will break by > removing -c capability from the htsearch CGI, it may be worth the risk > of having a compile-time option to revert to the old behaviour. Off the top of my head, I can't think of anything that would potentially break--given usual testing. Granted, that's the definition of "unforseen." :-) In some sense, the rug will be pulled out from many users even with a compile-time option. It clearly shouldn't be the default, and I doubt RPM maintainers will want to use the option. So anyone just running ./configure; make, or installing a binary will have to rewrite. > I really don't follow you on this point. If the CONFIG_DIR environment > variable is vulnerable in the htsearch CGI, then theoretically any > environment variable in any CGI is equally vulnerable, so there's no > CGI security at all. After all, you could override LD_LIBRARY_PATH, > or REQUEST_METHOD, or PATH and IFS. What I don't get is how a hostile > user could override any arbitrary environment variable in a CGI program. For this reason, actually, CGIs are supposed to set PATH themselves. <http://www.w3.org/Security/Faq/wwwsf4.html#CGI-Q8> >From the "Safe CGI programming FAQ" --- DON'T MAKE ASSUMPTIONS ABOUT YOUR ENVIRONMENT: Just because cgi-bin programs are traditionally executed within the sanitized environment provided by the webserver, on multiuser systems it may be possible for other users to execute your cgi-bin programs, or force an execution of them in an unexpected context. --- Can I come up with all sorts of other nasty situations if a local user hijacks the CGI environment variables? Yes. Do I see a good reason to keep the getenv("ONFIG_DIR")? No. Again, it might be convenient, but I think it adds a potential (if convoluted) hole. Just my $0.02, -Geoff _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
