Tom Lane wrote:
> Tim Bunce <Tim(dot)Bunce(at)pobox(dot)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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-02-03 19:04:47|
|Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
|Previous:||From: Alex Hunsaker||Date: 2010-02-03 18:49:01|
|Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]|