Date: Sun, 16 Feb 1997 13:05:00 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@hyperreal.com
Subject: Re: [PATCH] limiting server-info's accessibility
In-Reply-To: <97021615073936@decus.org>
Message-ID: <Pine.LNX.3.95dg2.970216123905.13142C-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

I wonder if the guy who reported it has reverse IP maps set up for
all the addresses on the webserver.  If he allows CGI on the webserver
then he also has to ensure that all his rc files are mode 600, and so
is the actual httpd.conf on disk.  I hope he's running httpd with limit
coredumpsize 0.  Otherwise customers with machine access are going to be
able to find out the other customers' names pretty easily...

I'd really like to see this in contrib in 1.2.

Couldn't the user use AddModule/ClearModuleList to control this
with already existing features?  Oh wait, no, it's global server config
rather than vhost config.

Ok, here is a more general syntax that solves this problem in the core:

    InvokeModule module-name [on|off]

    This directive can be given in directory contexts.  If given the
    off directive, the module named has none of its methods invoked if
    the uri crosses the context.  Otherwise it enables the module.

Implementation should include a bitvector in the core dir config to
ensure that run_method()/invoke_handler() can determine quickly if the
module should be invoked.  Plus there is a bit of fun doing merges, there
actually need to be three bitvectors, one that is the current state,
one that lists all the ONs and one that lists all the OFFs.

Definately not for 1.2, but something like this could go into 2.0.

Dean

On Sun, 16 Feb 1997, Rodent of Unusual Size wrote:

> >From the fingers of Randy Terbush flowed the following:
> >
> >These kind of changes border on feature changes IMO. I fail to
> >see the sensitivity of this information. When do we draw the
> >line.
> 
>     The case of the person who reported this seems to say it best: he's
>     offering multiple virtual hosts to multiple customers.  He was
>     concerned (and I would be, too) that his customers could breach the
>     privacy curtain and see a) the customer list, and b) the other
>     customers' configurations.  Roughly tantamount to publishing your
>     business plan (well, maybe not *that* bad ;-).
> 
> >Even *I* (a known to be "lets add one more goodie" supporter) sees
> >that it is time to shove this thing out the door.
> 
>     If you want to defer this until b8, that's cool with me - but I
>     think it needs to be addressed before 1.2final if the next after
>     that is 2.0..
> 
>     #ken    :-)}
>