Re: Controlling changes in plpgsql variable resolution

Robert,

>> Hmmmm. I don't see any reason why this couldn't be set by any user at
>> runtime, really. From a security standpoint, it's less of a risk than
>> search_path, and we allow anyone to mess with that.
>
> That's like saying that it's less of a risk than a group of rabid
> tyrannosaurs in a kindergarten classroom.

No, it's like saying "I don't see a point in putting a burglar alarm on
the windows when the door isn't even locked."

Making this GUC suset would make it far less useful to users trying to
gradually upgrade their infrastructures, and make it more likely that
many/most of our users would just set it to backwards-compatible in
their postgresql.conf and not fix anything. In fact, I'd go so far as
to say that if it's suset, we might as well make it sighup because
postgresql.conf is the *only* place anyone will touch it.

In a secure database setup, none of the functions belong to the
superuser. Yet an suset would mean that the function owner couldn't set
the parameter for their own functions, which is the most obvious place
to set it.

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.

--Josh Berkus