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

On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> >>
> >> >    SPI functions are not available when the code is run.
> >>
> >> Hrm, we might want to stick why in the docs or as a comment somewhere.
> >> I think this was the main concern?
> >>
> >> * We call a plperl function for the first time in a session, causing
> >>    plperl.so to be loaded.  This happens in the context of a superuser
> >>    calling a non-superuser security definer function, or perhaps vice
> >>    versa.  Whose permissions apply to whatever the on_load code tries
> >>    to do?  (Hint: every answer is wrong.)
> >
> > It's hard to convey the underlying issues in a sentence or two. I tried.
> > I'm not sure it's worth it. (Though if anyone thinks it is I'd be happy
> > to get some specific suggestions for the wording to use.)
>
> All I know is I thought hrm... Why cant you have SPI ? It seems useful
> and I dont immediately see why its a bad idea. So I dug up the old
> threads. Im just afraid say in a year or two we will forget why we
> disallow it.

Ah, yes, a comment is certainly easier to write up. I'll add one
and include a link to the relevant thread in the archives.
Thanks for the example.

> >> There does seem to be the risk that I may not have plperl GRANTed but
> >> I can make any plperl function elog(ERROR) as long as they have not
> >> loaded plperl via a plperl_safe_init.  We can probably fix that if
> >> people think its a valid dos/attack vector.
> >
> > Interesting thought. If this is a valid concern (as it seems to be)
> > then I could add some logic to check if the language has been GRANTed.
> > (I.e. ignore on_plperl_init if the user can't write plperl code, and
> > ignore on_plperlu_init if the user can't write plperlu code.)
>
> Well Im not sure. As a user I can probably cause havok just by
> passing interesting values to a function. It does seem inconsistent
> that you cant create plperl functions but you can potentially modify
> SHARED. In-fact if you have a security definer plperl function it
> seems quite scary that they could change values in SHARED. But any
> plperl function can do that anyway. (do we have/need documentation
> that SHARED in a plperl security definer function is unsafe?) So I
> dont think its *that* big of deal as long as the GRANT check is in
> place.

I don't see a significant issue in security definer and %_SHARED from
what you've said above. Authors of security definer functions should
naturally take care in how they use their argument values and %_SHARED.

I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
on IRC for the pointer).

Tim.