Re: Best practice running a shared DB hosting server

On Mon, Aug 18, 2008 at 10:55:27AM -0600, Scott Marlowe wrote:
> On Mon, Aug 18, 2008 at 10:38 AM, Thomas Jacob <jacob(at)internet24(dot)de> wrote:
> > On Mon, 2008-08-18 at 11:48 -0400, Robert Treat wrote:
> >
> >> Yes, I think the whole "security through obscurity" argument is a cop out to
> >> get around postgresql's design choices (in this perticular instance anyway,
> >> in many cases its valid).
>
> No, it's a way of preventing the wasting of countless man hours making
> changes that accomplish exactly nothing in terms of SECURITY. Now, it
> may help with your particular business rules to have that information
> hidden. But if you think hiding who the other users are gives you any
> real measure of security you are sorely mistaken.

Knowing who else is running their database
the same server can easily become a matter of security.

Relying on the "hiddeness" of usernames, databases, tables
etc. as a sole security measure is one thing. That's after
all what's classically called security through obscurity. However
I want security AND obscurity, or rather anonymity, if I use
a rented service.

A scenario:

PostgreSQL would be the first major piece of code without any
security holes. Just because they haven't been published yet,
doesn't mean there aren't any. Imagine a 0-day exploit
making its way round the Internet that lets you log into
any database, and a large shared database
server in a web-hosting environment. It's well-nigh certain
that somebody's web application will have security problem. If
that can be exploited, an attacker might gain access
to a user database. But if that attacker cannot find
out anything about other databases, maybe that 0-day exploit
wouldn't help them, because they would need the name
of database to connect. If my database and user names
are random strings of a certain minimum length, the
task of breaking into other databases might become
impossible.

But sure, security/anonomity are not the only thing that matters,
and at the end of the day it's up to the PostgreSQL developers
to decide what they want to work on.

> Very few users actually need to hide user info in the system catalogs
> etc from other users. For the vast majority who want it it's not

The vast majority of current users maybe. But then again, most people
use database systems (in the loosest possible sense ;-) in Web applications,
and most of these use MySQL today, in a shared hosting environment.

PostgreSQL has an excellent documentation that is also much logically constructed
then MySQL's, and let's not even talk about ACID, why not see as a
serious competitor to MySQL in the "lesser" realms.

This might not matter much to the professional database administrators though.