Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tim Bunce <Tim.Bunce@pobox.com>, Alex Hunsaker <badalex@gmail.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2010-02-03T18:51:47Z
Lists: pgsql-hackers
Tom Lane wrote: > Tim Bunce <Tim.Bunce@pobox.com> writes: > >> 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). >> > > What exactly are you proposing to check, and where, and what do you > think that will fix? > > If the concern is that someone could sabotage the behavior of a plperl > function by changing things around in the perl_init script, then I think > we have to forget about making it USERSET. Whether someone has been > granted permission to use plperl seems to me to have little to do with > whether it's okay to mess up a function (possibly a SECURITY DEFINER > one) belonging to someone else. > > > If we are seriously worried about use of %_SHARED in security definer functions then ISTM the right thing might be to have more than one and swap in the one for the effective user in a security definer function. Or possibly even disable it altogether in security definer functions. %_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. cheers andrew