Re: [v9.2] Fix Leaky View Problem

On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 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

No, you're missing my point completely. If we use a flexible options
syntax here, then we have to decide on what behavior CREATE OR REPLACE
should have for all future options, without knowing what they are yet,
or what behavior will be appropriate.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company