Re: leaky views, yet again

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 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.

Well, the approach you suggested of putting a security wrapper around
the output column might be bulletproof against that; I'm not entirely
sure, but I don't see a hole in it at the moment. The trouble with it
is that it's pretty bad from a performance point of view, at least
for columns that people are supposed to be able to use in WHERE clauses.
You couldn't index the wrapper expression either. So I'm not seeing
a universal solution there.

> 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?

Right, *column* filtering seems easy and entirely secure. The angst
here is about row filtering. Can we have a view in which users can see
the values of a column for some rows, with perfect security that they
can't identify values for the hidden rows? The stronger form is that
they shouldn't even be able to tell that hidden rows exist, which is
something your view doesn't try to do; but there are at least some
applications where that would be desirable.

regards, tom lane