Re: Add on_trusted_init and on_untrusted_init to plperl [PATCH]

Tim Bunce <Tim(dot)Bunce(at)pobox(dot)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, ...)
> + plperl.on_trusted_init runs inside the Safe compartment.

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.

> As I recall, Tom had concerns over the combination of PGC_USERSET and
> before-first-use semantics.

IIRC, what I was unhappy about was exposing shared library load as a
time when interesting-to-the-user things would happen. It looks like
you have got rid of that and instead made it happen at the first call
of a plperl or plperlu function (respectively). That seems like a
fairly reasonable way to work, and if it's defined that way, there
doesn't seem any reason not to allow them to be USERSET/SUSET.
But it ought to be documented like that, not with vague phrases like
"when the interpreter is initialized" --- that means nothing to users.

One issue that ought to be mentioned is what about transaction
rollback. One could argue that if the first plperl call is inside
a transaction that later rolls back, then all the side effects of that
should be undone. But we have no way to undo whatever happened inside
perl, and at least in most likely uses of on_init there wouldn't
be any advantage in trying to force a redo anyway. I think it's okay
to just define it as happening once regardless of any transaction
failure (but of course this had better be documented).

regards, tom lane