Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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