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