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

On Wed, Feb 3, 2010 at 12:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> %_SHARED has been around for several years now, and if there are genuine
>> security concerns about it ISTM they would apply today, regardless of
>> these patches.
>
> 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.

> I think a more reasonable answer is just to add a documentation note
> pointing out that %_SHARED should be considered insecure in a multi-user
> database.

Works for me. We probably want to do that anyway.

> is there any equivalent of changing search_path or otherwise creating
> trojan-horse code that might be executed unexpectedly?

Yes but not in the plperl variant. Only with plperlu or the
plperl.init GUCs marked SUSER could you do any of the above. Which
makes me think maybe the plperl.plperlu_init function could just have
a similar permission check to plperl.plperl_safe_init and be USERSET ?
Too gross?

> And if so is
> there any point in trying to guard against it?  AIUI there isn't
> anything that can be done in on_init that couldn't be done in somebody
> else's function anyhow.

Right, the point is you can only do that if you can make those
functions (or if someone prepared a nice function for you to use).

Maybe im just being paranoid. Leaving it the way it is now (USERSET)
is certainly easier. =)