[Xapian-devel] Omega changes

[James Aylett]

On Fri, Dec 17, 2004 at 05:53:18PM +0000, Olly Betts wrote:

> 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.

Aren't the defaults system-wide defaults? In which case it's only of
use there if you're the system admin, in which case I'd hope you can
keep (a) make your own security decisions, and (b) keep your
permissions in order. Many users in providing hosting environments
can't do this, and I tend to get worried about them.

Of course, they may well just install it and put everything in the
same directory. Not really sure what the solution to that is, although
we could try something ungainly like in-dir config => database files
must not be in the same directory. That's probably more effort than
sense, though, and doesn't actually solve that many problems anyway.

> 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.

You have to get pretty devious if the only thing you can run in the
environment is CGI/PHP (because of execution time limits). But I
agree; the best way of providing this kind of this securely is
something like Solaris Trusted Containers, or virtualising your OS
some other way. suexec or similar (userv, for instance) works okay for
CGI, if you're careful and know what you're doing. PHP is a lost cause
for security in shared environments.

> If you want to mix cgis and static content, nobody is forcing you to
> put your omega.conf in the same directory.

Except at the moment, you can't. If someone wants to mix cgis and
static content in a non-system installation, they have to put
omega.conf in the same directory as the CGI.

> We can document that this is a bad idea in this situation.

I'd be happy with that and:

> 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...)

Yes, but you can always ask the admin to restrict that environment
variable. SetEnv can be done at the directory level, for core server
configuration, and if the admin chooses that all users must do things
using the environment variable (with some mod_rewrite trickery you can
auto-set $HOME/.omega.conf or something), then that's their choice.

J

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james at tartarus.org                               uncertaintydivision.org