Re: [v9.2] Fix Leaky View Problem

2011/9/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>>> Robert Haas  09/25/11 10:58 AM >>>
>>>
>>> > I'm not sure we've been 100% consistent about that, since we
>>> > previously made CREATE OR REPLACE LANGUAGE not replace the owner
>>> > with the current user.
>>>
>>> I think we've been consistent in *not* changing security on an
>>> object when it is replaced.
>>
>>> [CREATE OR REPLACE FUNCTION does not change proowner or proacl]
>>
>> Good point.  C-O-R VIEW also preserves column default values.  I believe we are
>> consistent to the extent that everything possible to specify in each C-O-R
>> statement gets replaced outright.  The preserved characteristics *require*
>> commands like GRANT, COMMENT and ALTER VIEW to set in the first place.
>>
>> The analogue I had in mind is SECURITY DEFINER, which C-O-R FUNCTION reverts to
>> SECURITY INVOKER if it's not specified each time.  That default is safe, though,
>> while the proposed default of security_barrier=false is unsafe.
>
> Even though I normally take the opposite position, I still like the
> idea of dedicated syntax for this feature.  Not knowing what view
> options we might end up with in the future, I hate having to decide on
> what the general behavior ought to be.  But it would be easy to decide
> that CREATE SECURITY VIEW followed by CREATE OR REPLACE VIEW leaves
> the security flag set; it would be consistent with what we're doing
> with owner and acl information and wouldn't back us into any
> unpleasant decisions down the road.
>
Does the CREATE SECURITY VIEW statement mean a synonym of
CREATE VIEW ... WITH (security_barrier=true) ?

If so, it seems to me reasonable to keep the configuration when user
provides no explicit option.

1) an explicit WITH(security_barrier=true) / CREATE SECURITY VIEW
-> It always turns on a security_barrier option.

2) an explicit WITH(security_barrier=false)
-> It always turns off security_barrier option.

3) no explicit option / CREATE VIEW
-> Keep existing configuration, although inconsist with SECURITY DEFINER

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>