Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date
Msg-id 4B69C5C3.2020307@dunslane.net
Whole thread Raw
In response to Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
List 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


pgsql-hackers by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Next
From: Tom Lane
Date:
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]