Skip site navigation (1) Skip section navigation (2)

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

From: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date: 2010-02-03 17:56:53
Message-ID: 20100203175652.GD52427@timac.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
> >> 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).


In response to


pgsql-hackers by date

Next:From: Aidan Van DykDate: 2010-02-03 18:02:38
Subject: Re: PG 9.0 and standard_conforming_strings
Previous:From: Tom LaneDate: 2010-02-03 17:39:21
Subject: Re: PG 9.0 and standard_conforming_strings

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group