[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BOA was: An issue with Apache on Debian



Galen Hancock <galenh@bigfoot.com> wrote:

> On Sun, Apr 11, 1999 at 09:10:15PM +0200, Martin Stjernholm wrote:
/.../
> > Being a "metabug", i.e. a bug in the policy, accentuates it even more
> > since packages _have_ to implement this weakness and activate it by
> > default.
> 
> Hi, I'd just like to say that I don't think policy is actually as big a
> problem as you imply here. The relevant section says:
> 
> # 2.   Access to html documents
> # 
> # Html documents for a package are stored in /usr/doc/<package> and can
> # be referred to as http://localhost/doc/<package>/<filename>
> 
> This does not seem to require that /doc be available except when the
> service is being used from localhost. Arguably it does from context (the
> same document says /cgi-bin should point at /usr/lib/cgi-bin), but
> nevertheless Web server package maintainers do not need to wait for
> policy to be changed to correct the problem.

It's true that it doesn't say that a server package has to give access
to anyone else than localhost. However, when packaging a server that
doesn't have such filter features, the maintainer must either give
access to everyone or leave it out altogether. Afaics, the policy
forces the first alternative in that situation.

Also, restricting to localhost doesn't solve the problem entirely as
someone pointed out; if you e.g. happen to run a http proxy on the
computer it'd still be accessible for others.

(Besides the security issues here, I find this policy a bit bothersome
since it stipulates content in a service that I think the Debian user
should have full control over. Whether a user want to access /usr/doc
with a web browser shouldn't have anything to do with whether (s)he
want to run a www server and what content it should provide in that
case. A documentation server might be a good idea, but it should be a
separate package, running with appropriate restrictions on its own
port. Sure, it'd be neat if it could use the http daemon in case the
user has installed any, but that ought to be a secondary goal.)


Reply to: