Tom Lane wrote:

Andrew Dunstan <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to