From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | robertmhaas(at)gmail(dot)com, Kohei(dot)Kaigai(at)emea(dot)nec(dot)com, kaigai(at)kaigai(dot)gr(dot)jp, 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 02:38:18 |
Message-ID: | 20110926023818.GA13225@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Thanks,
nm
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Singer | 2011-09-26 02:39:00 | Re: Online base backup from the hot-standby |
Previous Message | Kevin Grittner | 2011-09-26 02:32:27 | Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build) |