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

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

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Alex Hunsaker <badalex(at)gmail(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 19:15:56
Message-ID: 3CCBD590-1927-4F1E-960C-4CB0E9F53E15@kineticode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Feb 3, 2010, at 11:04 AM, Tom Lane wrote:

> What I was actually wondering about, however, is the extent to which
> the semantics of Perl code could be changed from an on_init hook ---
> is there any equivalent of changing search_path or otherwise creating
> trojan-horse code that might be executed unexpectedly?

Yes.

> And if so is
> there any point in trying to guard against it?

No. This is Perl we're talking about. The DBA should vet code before putting it into on_perl_init.

> AIUI there isn't
> anything that can be done in on_init that couldn't be done in somebody
> else's function anyhow.

Correct.

Best,

David


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-03 19:15:58
Subject: Re: PG 9.0 and standard_conforming_strings
Previous:From: Josh BerkusDate: 2010-02-03 19:13:43
Subject: Re: PG 9.0 and standard_conforming_strings

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