Re: leaky views, yet again

Tom Lane  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