Re: Increasing security in a shared environment ...

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664