Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group