Skip site navigation (1) Skip section navigation (2)

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

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date: 2010-02-03 18:43:40
Message-ID: 34d269d41002031043u7b709855n708b6c220af93e36@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 3, 2010 at 11:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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?

Non plperl GRANTed people could modify the global $_SHARED variable.
Currently anyone that can make a plperl function can do anything they
want with $_SHARED.  So In my mind disallowing them to set
plperl.plperl_safe_init would make the permission model of $_SHARED
consistent.  No?  Now im not saying its a good permission model...

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-03 18:44:02
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous:From: Rod TaylorDate: 2010-02-03 18:37:28
Subject: Re: PG 9.0 and standard_conforming_strings

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group