Re: Controlling changes in plpgsql variable resolution

On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Tom has proposed some kind of odd special "options" syntax to get around
> this, but I think that's unnecessary.  So far on this thread, I haven't
> seen anyone engineer an actual function exploit by using this setting; I
> personally can't come up with one off the top of my head which doesn't
> require the attacker to be the table owner, the function owner, or the
> superuser themselves.  Also keep in mind what we're patching here is an
> unmaintanable and insecure practice anyway, which is the ambiguous use
> of variable names which match column names.
>
> So, I'm saying: make it a userset.

I couldn't disagree more strongly. .conf entries that adjust how
plpgsql funtions operate in a very central way will 'fork' plpgsql
develoeprs so that you have one group of people using method 'a' and
another using method 'b'. Nobody bothers to fix legacy code and now
we have a first class mess. All code intended to run on servers you
don't control (like library code) now needs to be decorated with 'set
local...' which defeats the whole purpose. IMO, guc settings that
control how sql behaves should be avoided at all costs. You should be
able to look at a piece of code and explicitly determine what it does.
At least with #option, knowing the server version and the function
body is enough. if you want to support multiple behaviors but don't
like #option, i think the only alternative is to version the plpgsql
language somehow and decorate 'create function' with the version. Tom
didn't like that idea, but it still beats GUC imo.

merlin