Re: Can we still trust plperl?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Tim Bunce" <Tim(dot)Bunce(at)pobox(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can we still trust plperl?
Date: 2010-03-11 14:49:13
Message-ID: 4B98AE89020000250002FC68@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> I'm wondering if we can reasonably continue to support plperl as
> a trusted language

> would still be plperlu, with the downside that the functions have
> to be installed by a superuser. One of my PGExperts colleagues
> told me his reaction was "Well, I might just as well use plperlu",
> and that pretty well sums up my reaction.

Well, I can see where running plperl with this module would be no
more safe than running plperlu, so I don't really understand the
purpose of the module; however, to install this module you need to:

| Set the PERL5OPT before starting postgres, to something like this:
| PERL5OPT='-e "require q{plperlinit.pl}"'
| and create a plperlinit.pl file in the same directory as your
| postgres.conf file.
| In the plperlinit.pl file write the code to load this module, plus
| any others you want to load and share subroutines from.

I don't see where plperl is unsafe unless you do those things. A
user who can do those things can likely subvert your database in
other ways, no?

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kenneth Marshall 2010-03-11 14:52:11 Re: Can we still trust plperl?
Previous Message Tom Lane 2010-03-11 14:39:31 Re: operator exclusion constraints