Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date: 2010-02-03 19:29:14
Message-ID: 1804.1265225354@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alex Hunsaker <badalex(at)gmail(dot)com> writes:
> On Wed, Feb 3, 2010 at 12:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yes. I am not at all happy about inserting nonstandard permissions
>> checks into GUC assign hooks

> I think Tims solution is just to check in plperl.c right before we
> eval it so not at SET time.

Well, that would be *completely* wrong/useless. What you would find out
is the ID of the user who directly called the function, which would have
nothing at all to do with the privileges of whoever set the GUC.

I'm leaning in the same direction as Robert: let's just make all three
of these SUSET and stop worrying. It's not real clear that there's much
of a use-case for letting unprivileged users set on_plperl_init anyway.
Also, we can always back it off later if we decide it's safer than it
looks.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Mielke 2010-02-03 19:30:15 Re: PG 9.0 and standard_conforming_strings
Previous Message Mark Mielke 2010-02-03 19:25:45 Re: PG 9.0 and standard_conforming_strings