Re: Increasing security in a shared environment ...

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Re: Increasing security in a shared environment ...
Дата
Msg-id 20040329182900.O51637@ganymede.hub.org
обсуждение исходный текст
Ответ на Re: Increasing security in a shared environment ...  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Mon, 29 Mar 2004, Andrew Dunstan wrote:

> It's that "probably" that niggles a bit. I don't know what usage
> patterns other people have, and since my typical use is exactly *one*
> user other than the owner/dba, and all access is mediated by my
> middleware, none of this affects me. ISTM we need to cater for as broad
> a set of usage patterns as is reasonable.

In my case, I have a dozen clients running OpenACS, all sharing the
postmaster instance ... now, at the pg_hba.conf level, the database is
restrict to userid @ IP ... so, I'm generally not too concerned about
ClientA being able to access ClientBs database ... but "just in case" an
admin somehow makes a mistake with the pg_hba.conf file, not being to find
out about other databases in the system would be nice ...

> What is not clear to me is how we would even decide which databases to
> hide, if it is not an all or nothing deal. Marc's phrase "those
> resources that they have permissions to see" doesn't define it nearly
> nicely enough. Say I block access to db foo to all users but bar via
> pg_hba.conf. Would we then want to prevent all other users from seeing
> foo in the list of databases? Things like that are why I started
> exploring a somewhat broader approach.

by default, pgsql superuse would see everything

usera, when doing a \l, would only see those databases that are owned by
usera ... maybe have some sort of GRANT ALL ON database so that userb
would see it listed to.

userc, altho not owner of any database, would ahve grant access to usera's
database, and see only that one ...

inside of usera's database, even though userc had access to the database,
a 'GRANT REVOKE' on a specific table would result in that table not being
seen in a \d listing ...

As to 'SELECT * FROM pg_database;' or 'SELECT * FROM pg_class' ... similar
to pg_shadow ... move it to a different name and have a VIEW on the
appropriate system tables that auto-adds something to the effect that the
list is restricted to those with access to those tables ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: int2[] vs int2vector in pg_catalog?
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Better support for whole-row operations and composite types