On Wed, Feb 03, 2010 at 02:04:47PM -0500, Tom Lane wrote:
> Andrew Dunstan <and...@dunslane.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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
