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]
|
Список | 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 по дате отправления: