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

On Wed, Feb 03, 2010 at 02:04:47PM -0500, Tom Lane 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 --- they are not really meant for that
> and I think there could be unexpected consequences. Without a serious
> demonstration of a real problem that didn't exist before, I'm not in
> favor of it.

I wasn't thinking of using GUC assign hooks (as that simply hadn't
occured to me). I was thinking of just ignoring on_plperl_init if
the user wasn't allowed to use the plperl language. Something like:

if (user_is_su_or_has_usage_of('plperl')) {
... eval the on_plperl_init code ..
}

> 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.

That's seems worth anyway. I'll add a note along those lines.

> What I was actually wondering about, however, is the extent to which
> the semantics of Perl code could be changed from an on_init hook ---
> is there any equivalent of changing search_path or otherwise creating
> trojan-horse code that might be executed unexpectedly?

This seems like a reasonable 'vector of first choice':

SET plperl.on_plperl_init = '$SIG{__WARN__} = sub { ... }';

and then do something to trigger a warning from some existing plperl
function. So I think the answer is yes.

> 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.

(The issue here is with on_plperl_init, not on_init or on_plperlu_init as they're SUSET).

There isn't anything that can be done in on_plperl_init that can't be
done in plperl in terms of what perl code can be compiled.
It seems there is a plausable vector for trojan-horse code though, so I
think the key issue if this could be exploited in a security definer
scenario.

Tim.