Re: Increasing security in a shared environment ...

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Increasing security in a shared environment ...
Date: 2004-03-29 17:09:01
Message-ID: 4068582D.2030203@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christopher Kings-Lynne wrote:

>> "The \l command should only list databases that the current user is
>> authorized for, the \du command should only list users authorized for
>> the
>> current database (and perhaps only superusers should get even that much
>> information), etc. Perhaps it is possible to set PG to do this, but
>> that
>> should probably be the default."
>>
>> This is from a PgSQL vs MySQL thread on -general ... how hard would
>> it be
>> make it so that a non-superuse user can't do a \l and see everyone's
>> databases? Or, when doing a \d in a database you are able to connect
>> to,
>> it would only show those tables that you are authorized for?
>
>
> Well, you can just go SELECT * FROM pg_database; so fixing \l won't
> do anything.
>
> I too would like to see more security in this respect, but it will be
> difficult if not impossible to implement methinks...
>

I just played around briefly with removing *all* public access to a
couple of catalog tables - pg_class and pg_attrdef. Obviously this
breaks things like \d and friends. I'm not sure how much else it might
break - certainly a non-privileged user was still able to select from a
table, and create and drop a table. Maybe we should look at some
paranoid settings for the catalog tables as an option for "create database".

My previous answer to this question has been "use a middleware layer
that exposes just the operations you want exposed". But this issue has
come up a few times so maybe some more thought is needed. Of course, we
are only talking about metadata here, not user table contents, but maybe
some people have a justifiable need to hide even the metadata.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2004-03-29 17:20:59 Re: Increasing security in a shared environment ...
Previous Message Euler Taveira de Oliveira 2004-03-29 17:08:04 Re: Increasing security in a shared environment ...