Re: [v9.2] Fix Leaky View Problem

On Sat, Oct 08, 2011 at 09:11:08AM +0200, Kohei KaiGai wrote:
> 2011/10/8 Noah Misch <noah@leadboat.com>:
> > On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
> >> My preference is still also WITH(security_barrier=...) syntax.
> >>
> >> The arguable point was the behavior when a view is replaced without
> >> explicit WITH clause;
> >> whether we should consider it was specified a default value, or we
> >> should consider it means
> >> the option is preserved.
> >> If we stand on the viewpoint that object's attribute related to
> >> security (such as ownership,
> >> acl, label, ...) should be preserved, the security barrier also shall
> >> be preserved.
> >> On the other hand, we can never know what options will be added in the
> >> future, right now.
> >> Thus, we may need to sort out options related to security and not at
> >> DefineVirtualRelation().
> >>
> >> However, do we need to limit type of the options to be preserved to
> >> security related?
> >> It is the first case that object with arbitrary options can be replaced.
> >> It seems to me we have no matter, even if we determine object's
> >> options are preserved
> >> unless an explicit new value is provided.
> >
> > Currently, you can predict how CREATE OR REPLACE affects a given object
> > characteristic with a simple rule: if the CREATE OR REPLACE statement can
> > specify a characteristic, we don't preserve its existing value. ?Otherwise, we
> > do preserve it. ?Let's not depart from that rule.
> >
> > Applying that rule to the proposed syntax, it shall not preserve the existing
> > security_barrier value. ?I think that is acceptable. ?If it's not acceptable, we
> > need a different syntax -- perhaps CREATE SECURITY VIEW.
> >
> No. It also preserves the security-barrier flag, when we replace a view without
> SECURITY option. The only difference is that we have no way to turn off
> security-barrier flag explicitly, right now.
> 
> The major reason why I prefer reloptions rather than "SECURITY" option is
> that allows to reuse the existing capability to store a property of relation.
> It seems to me both of syntax enables to achieve the rule to preserve flags
> when a view is replaced.

Yes, there are no technical barriers to implementing either behavior with either
syntax.  However, CREATE OR REPLACE VIEW ... WITH (...) has a precedent guiding
its behavior: if a CREATE OR REPLACE statement can specify a characteristic, we
don't preserve its existing value.

> >> Any other ideas?
> >
> > Suppose we permitted pushdown of unsafe predicates when the user can read the
> > involved columns anyway, a generalization of the idea from the first paragraph
> > of [1]. ?Would that, along with LEAKPROOF, provide enough strategies for shoring
> > up performance to justify removing unsafe views entirely?
> >
> The problem was that we do all the access control decision at the
> executor stage,
> but planner has to make a plan prior to execution. So, it was also reason why we
> have tried to add LEAKPROOF flag to functions.

Yes; we'd need to invalidate relevant plans in response to anything that changes
access control decisions.  GRANT and ALTER ... OWNER TO already do that, but
we'd need to cover pg_authid/pg_auth_members changes, SET ROLE, SET SESSION
AUTHORIZATION, and probably a few other things.  That might be a substantial
project in its own right.