On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote: > On Wed, Feb 3, 2010 at 09:31, Tim Bunce <tim.bu...@pobox.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.bu...@pobox.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
