Re: Disable databse listing for non-superuser (\l) ?

On Sat, Jul 25, 2009 at 5:23 AM, Bill Moran<wmoran(at)potentialtech(dot)com> wrote:
> Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
>>
>> On Fri, Jul 24, 2009 at 5:02 PM, Brian A.
>> Seklecki<lavalamp(at)spiritual-machines(dot)org> wrote:
>> > All:
>> >
>> > Any suggestions on how-to, or comments on a potential NFR, to disable
>> > non-superuser's from viewing the database list via \l?
>>
>> So, is this a misguided attempt at security through obscurity, or are
>> you looking at limiting the noise that users see when they look at
>> databases?
>
> I don't know about misguided, Scott.  Security takes many forms.
>
> If a client wants shared database hosting, but wants an assurance that
> other clients using the same shared DB server can't tell who else is
> using it?

Then they want something other than security. Which isn't necessarily
a bad thing, just don't fool yourself into thinking it's security.

> It's not security in the strict computer-science definition.  Obviously,
> if the proper ownerships and grants don't exist to protect the data, in
> addition to said obscurity, then the whole thing is pointless.

exactly.

>  But such
> obscurity _in_addition_ to proper, real security, has show usefulness
> in many areas.

Citation needed. I doubt it's ever made any real measurable difference.

> Take a properly secured SSH server, for example, and move it to an obscure
> port #.  Now you've reduced the number of mindless bots looking for
> unprotected root accounts, and your IDS solution that monitors the ssh
> logs is actually useful.  Of course, that's only effective if ssh is
> properly secured to begin with.

If it's secure, then it doesn't matter what port it's on. If it's not
secure, being on a secondary port is no great improvement.

> Many clients want the cost-effectiveness of shared DB hosting.  Many of
> them also want it kept under wraps that they're doing so.  The provider
> that can do such a thing gets the contract.  Those that complain about
> "it's not security, it's obscurity" do not get the contract.

Yep. And i can guarantee that having such a contract mens you've got
a customer that makes you wanna pull your hair out. Having dealt with
a few like that in the past. :)

But my very serious point on this is that postgresql isnt' designed to
hide such things from users, and changing it to do so takes a lot of
effort for no real return on investment. OTOH, having a psql client
that just uses a different set of queries so that it doesn't show the
other dbs could be actually useful and take little or no effort.
Given the lack of a serious clarification or answer from OP, I've not
been inclined to post anymore on this subject.