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