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

2010-01-28 Thread Tim Bunce
Now the dust is settling on the on_perl_init patch I'd like to ask for clarification on this next patch. On Fri, Jan 15, 2010 at 12:35:06AM +, Tim Bunce wrote: This is the fourth of the patches to be split out from the former 'plperl feature patch 1'. Changes in this patch: I think the

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

2010-01-28 Thread Tom Lane
Tim Bunce tim.bu...@pobox.com writes: I think the only controversial change is this one: - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs Both are PGC_USERSET. SPI functions are not available when the code is run. Errors are detected and reported as ereport(ERROR, ...) +

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

2010-01-28 Thread Andrew Dunstan
Tom Lane wrote: Isn't it a security hole if on_trusted_init is USERSET? That means an unprivileged user can determine what will happen in plperlu. SUSET would be saner. ITYM on_untrusted_init. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

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

2010-01-28 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: Isn't it a security hole if on_trusted_init is USERSET? That means an unprivileged user can determine what will happen in plperlu. SUSET would be saner. ITYM on_untrusted_init. Right, sorry, got 'em backwards.

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

2010-01-28 Thread Tim Bunce
On Thu, Jan 28, 2010 at 12:12:58PM -0500, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: Isn't it a security hole if on_trusted_init is USERSET? That means an unprivileged user can determine what will happen in plperlu. SUSET would be saner. ITYM

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

2010-01-28 Thread Tim Bunce
On Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com writes: I think the only controversial change is this one: - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs Both are PGC_USERSET. SPI functions are not available when the code is run.

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

2010-01-28 Thread David E. Wheeler
On Jan 28, 2010, at 12:01 PM, Tim Bunce wrote: Once the previous patch lands I'll post an update to this patch with those changes applied. Ds the Add on_perl_init and proper destruction to plperl patch the one you're waiting on, then? Best, David, who loses track of these things -- Sent

[HACKERS] Add on_trusted_init and on_untrusted_init to plperl [PATCH]

2010-01-14 Thread Tim Bunce
This is the fourth of the patches to be split out from the former 'plperl feature patch 1'. Changes in this patch: - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs Both are PGC_USERSET. SPI functions are not available when the code is run. Errors are detected and