Re: Increasing security in a shared environment ...

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