[Xapian-devel] Omega changes

[Olly Betts]

On Fri, Dec 17, 2004 at 05:16:34PM +0000, James Aylett wrote:
> On Fri, Dec 17, 2004 at 04:12:37PM +0000, Olly Betts wrote:
> 
> > > I propose changing the configuration file search to read an environment
> > > variable "OMEGA_CONFIG_FILE".
> > 
> > Setting an environmental variable (at least for apache) requires admin
> > access to the webserver configuration, or (assuming it's configured to
> > allow you to) the creation of a .htaccess file, or some sort of wrapper
> > around the CGI (e.g. a shell script which exports the variable and execs
> > omega).  If .htaccess exists, the server has to read it for anything
> > served from that directory, which is potentially quite an overhead.
> 
> If you can't affect your VHOST config, and you can't use .htaccess,
> and you can't write a simple wrapper (we could supply one) then you
> should move to a different hosting provider.

I can always (I suspect) use a simple wrapper.  But it's not a clean
solution.  When it comes down to it, the main argument against
omega.conf in the cgi directory is aesthetic, so if the alternatives are
ugly too, what do we gain except annoyed users?

> Seriously. I can't stress
> how much of a security hole I see this as being, because the
> alternatives are (a) to write a Redirect/RedirectMatch directive in
> your .htaccess/VHOST/directory or server config, or (b) expose
> implementation details. And the default is (b).

Calling it a security hole is alarmist - if omega.conf is readable, it's
an information leak.  The information would only be of use if there's
a hole elsewhere.  This feature is NOT the security hole.

If this is really the problem you seem to think, so is storing your
databases, templates, and log files in the default locations.  I could
see more of an argument here if omega.conf were to contain values which
didn't have defaults.

Note also that this configuration file has to be readable by the user
the http server runs as, so anyone who can put dynamic content such as
CGI scripts or PHP on the server (legitimately or via a hole) will be
able to read it.  Even not knowing the pathname is little obstacle
if you can put content on the server.

Unless you use suexec, in which case you can make it only readable by
the user omega runs as - but then it can't be served as static web
content anyway.

Also this is only an issue if you mix cgis in the same directory as
ordinary files.  If you use a separate cgi-bin directory, then there's
no problem at all.  Call me old fashioned, but I still prefer the
latter.  Not least because anyone changing the server config has to
be a more devious bungler to make your CGI scripts download instead of
run.

If you want to mix cgis and static content, nobody is forcing you to
put your omega.conf in the same directory.  We can document that this
is a bad idea in this situation.

I wouldn't object to adding the environmental variable as an option
(perhaps even taking precedence over looking next to the cgi, although
that would be extremely annoying if the admin is using it in the server
configuration, so perhaps not...)

Cheers,
    Olly