Re: Increasing security in a shared environment ...

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Increasing security in a shared environment ...
Дата
Msg-id 4068582D.2030203@dunslane.net
обсуждение исходный текст
Ответ на Re: Increasing security in a shared environment ...  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Ответы Re: Increasing security in a shared environment ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
Re: Increasing security in a shared environment ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: markw@osdl.org
Дата:
Сообщение: Re: PostgreSQL block size vs. LVM2 stripe width
Следующее
От: Euler Taveira de Oliveira
Дата:
Сообщение: Re: Increasing security in a shared environment ...