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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Дата
Msg-id 4B69C5C3.2020307@dunslane.net
обсуждение исходный текст
Ответ на Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alex Hunsaker
Дата:
Сообщение: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]