www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: other/2805: Apache won't start with syntactically incorrect <virtual hosts><
Date Fri, 07 Aug 1998 19:30:01 GMT
The following reply was made to PR other/2805; it has been noted by GNATS.

From: Marc Slemko <marcs@znep.com>
To: Malcolm Hutty <malcolm@ivision.co.uk>
Cc: apbugs@apache.org
Subject: Re: other/2805: Apache won't start with syntactically incorrect
 <virtual hosts><
Date: Fri, 7 Aug 1998 12:22:57 -0700 (PDT)

 On Fri, 7 Aug 1998, Malcolm Hutty wrote:
 
 > > Synopsis: Apache won't start with syntactically incorrect <virtual hosts>
 > > in httpd.conf
 > > It is a very bad thing to magically ignore settings that
 > > are incorrect.  There is no way to tell if it is just
 > > an unimportant vhost that can be ignored or if it is
 > > a very important directive that will result in major
 > > problems (eg. huge security hole) if not done properly.
 > 
 > My bug report is a serious ISP situation.
 > 
 > There is a big difference between ignoring an incorrect directive and not setting 
 > up one of the several virtual servers: Apache is commonly run with many 
 > independent IP based virtual servers. You cannot tell if a directive is important, 
 > but it is always true is that one less virtual server is better than none at all.
 
 Perhaps it is always true for _YOU_, but that is a very dangerous
 assumption to make in the general case.  It could lead to anything from
 serious security holes to very embarassing situations if the wrong
 documentroot is used for things.
 
 > 
 > If a directive for a virtual host is malformed it could result in that server being

 > compromised, and so that virtual host should not be started. However that 
 > malformed directive would only have affected a single virtual host if it had 
 > succeeded, so it should only affect that one if it fails. Of course, my bug report 
 > does not apply to global directives.
 > 
 > Example:
 > 
 > <virtualhost 10.1.1.1>
 > # This works
 > DocumentRoot /usr/httpd/htdocs1
 > RewriteRule  ^/private/(.*) /cgi-bin/private.cgi?$1
 > </virtualhost>
 > 
 > <virtualhost 10.1.1.2>
 > # This fails 
 > DocumentRoot /usr/httpd/htdocs2
 > ReriteRul  ^/private/(.*) /cgi-bin/private.cgi?$1
 > </virtualhost>
 > 
 > I can't see why 10.1.1.1 should not start, with 10.1.1.2 failing.
 
 There are many cases where it isn't that simple.  Apache shouldn't be
 randomly guessing when ti ignore directives.
 
 >  
 > > You can't let just anyone edit your *.conf files anyway, so
 > > I really don't see the point of ignoring errors.  If you
 > > want, you can run "httpd -t" (or apachectl configtest) to
 > > test config files before restarting.
 >  
 > As an ISP we give each of our customers their own virtualhost.
 > We would like to be able to give them an interface to insert their own
 > directives, at their own risk. 
 > 
 > We can make our own interface so that they can only edit their own bit of 
 > httpd.conf. Obviously they won't get direct access, but figure:
 > 
 > ....
 > <virtualhost 10.1.1.1>
 > #### PERL MATCH ME
 > #### INSERT FILE : /home/10.1.1.1/Apache.conf
 > #### END PERL MATCH
 > </virtualhost>
 > 
 > Then Perl script generates a new httpd.conf and a Suid program simply restarts 
 > server.
 
 And you just opened up your server to massive security holes.  We don't
 support that either.  You can't just give untrusted users the ability to
 make almost arbitrary modifications to your config file.
 
 > However we can't give let our customers insert their own directives if screwing 
 > up their own server would also screw everyone else's.
 
 Checking that the config file is valid won't do much to stop that.
 Regardless, as I already told you, you can just use the -t option to check
 a config file to see if it has syntax errors before accepting their
 changes.
 

Mime
View raw message