Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
От | Robert Haas |
---|---|
Тема | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
Дата | |
Msg-id | 603c8f071002031120u3185ca42v362dd0be6e0f9058@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] (Alex Hunsaker <badalex@gmail.com>) |
Список | pgsql-hackers |
On Wed, Feb 3, 2010 at 1:49 PM, Alex Hunsaker <badalex@gmail.com> wrote: > On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker <badalex@gmail.com> wrote: >> On Wed, Feb 3, 2010 at 11:28, Tom Lane <tgl@sss.pgh.pa.us> 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? >> >> Non plperl ... > > Put another way: > HEAD: only people with plperl granted can make functions to manipulate $_SHARED > PATCH: anyone can set plperl.plperl_safe_init (but note not > plperlu_init as its SUSER) and manipulate $_SHARED > Proposed fix: only people with plperl granted can set > plperl.plplerl_safe_init and hence restore HEAD behavior I think we should just not have any unprivileged-user-settable GUCs and then this problem goes away. Trying to test for GRANT privilege on the appropriate language seems like a big kludge, and I am doubtful that it's worth it. ...Robert
В списке pgsql-hackers по дате отправления: