Re: plperl Safe restrictions

From: David Helgason <david(at)uti(dot)is>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plperl Safe restrictions
Date: 2004-10-14 19:46:23
Message-ID: BA2F4853-1E19-11D9-A5EF-000A9566DA8A@uti.is
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On 14. okt 2004, at 21:09, Andrew Dunstan wrote:
> It has just been brought to my attention that we are being very
> restrictive about what we allow to be done in trusted plperl.
> Basically we allow the :default and :base_math set of operations (run
> perldoc Opcode or see http://www.perldoc.com/perl5.8.0/lib/Opcode.html
> for details of what these mean). In particular, we do not allow calls
> to perl's builtin sort, which is unpleasant, and on reviewing the list
> it seems to me we could quite reasonably allow access to pack and
> unpack also. bless and sprintf are also likely candidates for
> inclusion - I have not finished reviewing the list, and would welcome
> advice from perl gurus on this.

pack and unpack are unfortunately not safe. Very useful, but they allow
write/read access to random memory. It's really a shame perl doesn't
have a pragma to make them safe or have safe versions of them.

Bless should be OK, unless sensitive objects are provided to the
procedures.

A postgres question I don't know the answer to is whether allowing the
user to trigger a segfault is a security problem. If it isn't, several
opcodes may probably be allowed, including sort and sprintf. If it is,
well, you need only follow the perl5-porters list to know that there's
banal perl structures are continuously being found that will segfault
perl, some at compile time, other at runtime.

> On the other side, I think we should exclude the :base_io set which is
> part of the :default set (we don't want trusted plperl writing to
> stdout, for example - all IO should be forbidden).

Definitely out :)

> I know changing this at this stage of the dev cycle is bad, but I
> think it ought to be done. Unless there are loud squawks I will submit
> a patch RSN. It should be very low risk - one or two lines.

Take care what you open. Perl may be a fairly secure, but the complex
implementation means that problematic corner cases are regularly found.

d.
--
David Helgason,
Business Development et al.,
Over the Edge I/S (http://otee.dk)
Direct line +45 2620 0663
Main line +45 3264 5049

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jon Jensen 2004-10-14 19:51:04 Re: plperl Safe restrictions
Previous Message Andrew Dunstan 2004-10-14 19:44:14 Re: plperl Safe restrictions

Browse pgsql-patches by date

  From Date Subject
Next Message Jon Jensen 2004-10-14 19:51:04 Re: plperl Safe restrictions
Previous Message Andrew Dunstan 2004-10-14 19:44:14 Re: plperl Safe restrictions