From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Kohei(dot)Kaigai(at)emea(dot)nec(dot)com, thom(at)linux(dot)com, pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: [v9.2] Fix Leaky View Problem |
Date: | 2011-09-26 13:51:09 |
Message-ID: | CADyhKSUhm1D7=OjBZU+ptwOkL_pSB6PDj8akh7CCs4UEfzmMXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/9/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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.
>
Hmm. Indeed, it seems to me fair enough reason.
In this syntax case, the only way to clear the security_barrier flag
is to drop view
once, then create a view, isn't it?
And, is the security_barrier flag still stored within reloptions field?
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2011-09-26 13:53:49 | Re: Inlining comparators as a performance optimisation |
Previous Message | Dimitri Fontaine | 2011-09-26 13:34:45 | Upgrading Extenions from 8.4 |