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

Re: plperl & sort

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff <threshar(at)threshar(dot)is-a-geek(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: plperl & sort
Date: 2008-11-04 21:43:05
Message-ID: 4910C1E9.2030109@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-bugs

Alex Hunsaker wrote:
> On Tue, Nov 4, 2008 at 12:43, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
>   
>> It has something to do with anon subs not sure what...
>>     
>
> It has to do with us returning the anonymous sub inside of the safe
> and then calling the function outside of the safe (or at least in a
> different namespace)
>
> we do something eqvilient to this:
> my $func_ptr = $safe->reval('sub { ... }');
> $func_ptr->();
>
> because safe makes its own namespace from perldoc Safe
> The "root" of the namespace (i.e. "main::") is changed to a
> different package and code evaluated in the compartment cannot
>  refer to variables outside this namespace, even with run-time
>  glob lookups and other tricks.
>
> I only see one way to "fix" this which is to do something groddy like
> share a global variable between the safe and the real interpreter.
> Something like:
>
> my $_pl_sub;
> sub call_pl_sub
> {
>     retrun $_pl_sub;
> }
>
> $safe->share(qw(call_pl_sub);
>
> my $sub = $safe->reval('sub { ...}');
>
> $_pl_sub = $sub;
> $safe->reval('call_pl_sub();');
>
> Note I tried just sharing $_pl_sub and doing
> $safe->reval('$_pl_sub->()'); but I just get 'Undefined subroutine
> &main::'
>
> Should I work up a patch? Assuming someone confirm this?
>
>   

OK, the first thing to note is that there is an easy workaround, which 
is to use a sort routine that doesn't need $a/$b. Example:

    create or replace function mysort() returns text language plperl as $f$

        my $sfunc = sub ($$) { $_[0] <=> $_[1] };

        my @vals = (5,3,4,2,7);

        return join(' ',sort $sfunc @vals);

    $f$;

We need to document that, and given that this exists I think we don't 
need to backpatch old versions.

Beyond that, we need to be very careful with any "solution" that we 
don't upset the moderately fragile security of trusted plperl, and I'm 
going to look fairly skeptically at anything that changes the way we set 
up and call functions. But by all means if you can come up with a robust 
way of allowing the more traditional way of calling sort routines, send 
it in. Sharing globals between the Safe and non-Safe worlds is not a 
solution - we removed an instance of that not long ago for security reasons.

cheers

andrew


In response to

Responses

pgsql-bugs by date

Next:From: Alex HunsakerDate: 2008-11-04 22:02:11
Subject: Re: plperl & sort
Previous:From: JeffDate: 2008-11-04 20:51:27
Subject: Re: plperl & sort

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