Tom Lane <t...@sss.pgh.pa.us> wrote: > I don't believe we can solve Kevin's version of the problem, which > is whether a stalker can verify the address of a victim that he's > not supposed to be able to see. I'm surprised; I thought that we were already there. If someone has SELECT rights on that view, how would they be able to verify an address? More importantly, do you see a way to find out what a particular party's address is when it is unknown? I'm getting the unsettling feeling that I've been missing something important.... By the way, I didn't mean to leave the name column out of the view, but I guess I inadvertently demonstrated another way in which I think the current view implementation adds security. If the column isn't exposed to the view at all, I don't see how access to the view can leak much about the omitted column, but perhaps I'm missing something there, too? > BTW, I thought Kevin's example view was mighty interesting, > because it applies the security check in a totally different way > than what we've all been implicitly assuming. Ie, instead of > select * from underlying_table where security_check(); > he did > select security_wrapper(underlying_col) from underlying_table; > Offhand these approaches seem to have quite different properties. We do both (sometimes in the same query), but obfuscating detail about a database object (case, party, address) is much more common than hiding the existence of these objects. The obfuscated columns are usually not indexed or usable as search criteria. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
