From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: Controlling changes in plpgsql variable resolution |
Date: | 2009-10-21 20:50:54 |
Message-ID: | 603c8f070910211350g35ba5088ldd758086ec7eacc4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 21, 2009 at 4:28 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> 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.
I agree. We already have one case (search_path) where you potentially
can't accurately predict the semantics of the function without knowing
something about the calling environment. That means every
security-definer function, to be secure, has to explicitly control the
search path. That's bad.
I actually think that we should not have a GUC for this at all. We
should have a compiled-in default, and it should be error. If you
want some other behavior, decorate your functions with #option. The
only way this is not a train wreck is if the semantics are set *from
within the function*. Having any portion of the semantics, no matter
how seemingly trivial, imported from the outside is just asking to get
whacked on the head with a stream of difficult-to-diagnose
misbehavior. Even if we assume, with a heavy dose of unjustified
optimism, that no security vulnerabilities will result, it's not going
to be fun or pleasant.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2009-10-21 20:55:04 | Re: alpha2 bundled -- please verify |
Previous Message | Simon Riggs | 2009-10-21 20:40:46 | Re: Hot standby, prepared xacts, locks |