Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>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 -
>>
>>
>
>pg_dump, for starters ...
>
>
Right. So I played around a little more and restored read priv but only
for the db owner, which seemed to work, and makes some sense to me.
>I'm not sure that hiding the contents of the current database's catalog
>is all that useful a goal in practice. If you have two users sharing a
>database then probably you *want* them to be able to exchange some
>amount of information.
>
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.
>I can see the use-case for hiding contents of
>the shared tables (pg_database, pg_shadow, pg_group) in installations
>where different users have different databases but you want to run just
>one common postmaster. Even there, though, it doesn't seem all that
>essential --- its only usefulness is security by obscurity.
>
>
>
That phrase to me denotes "something they could easily discover if only
they knew about it". How would they discover the contents of these,
assuming they did know about them and we blocked access?
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.
cheers
andrew
