Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> CREATE SECURITY VIEW, anyone?
> That may be the best approach, but I think it needs more than one line
> of exposition. The approach I proposed was to test whether the user
> has privileges to execute the underlying query directly without going
> through the view. If so, we needn't be concerned. If not, then we
> start thinking about which functions/operators we trust.
Ummm ... that makes semantics dependent on the permissions available at
plan time, whereas what should matter is the permissions that exist at
execution time. Maybe that's all right for this context but it doesn't
seem tremendously desirable.
> Perhaps there is some value to having a knob that goes the opposite
> directions and essentially says "I don't really care whether this view
> is leaky from a security perspective". But presumably we don't want
> to deliver that behavior by default and require the user to ask for a
> SECURITY VIEW to get something else - if anything, we'd want CREATE
> VIEW to create the normal (secure) version and add CREATE LEAKY VIEW
> to do the other thing.
-1 on that. We will get far more pushback from people whose application
performance suddenly went to hell than we will ever get approval from
people who actually need the feature. Considering that we've survived
this long with leaky views, that should definitely remain the default
behavior.
regards, tom lane
