Re: [BUGS] Behavior change of FK info query
Zahid Khan wrote: > > Hi, > > I am getting one failures in odbc application with 8.3 server which is > related to foreign key information. Which ODBC driver version are you using? Remember that newer drivers work with older database servers, but older drivers may not work with newer database servers. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Behavior change of FK info query
I am using 8.3.1 driver ,Is this changed in any new version ? --- On Tue, 11/4/08, Craig Ringer <[EMAIL PROTECTED]> wrote: From: Craig Ringer <[EMAIL PROTECTED]> Subject: Re: [BUGS] Behavior change of FK info query To: [EMAIL PROTECTED] Cc: pgsql-bugs@postgresql.org Date: Tuesday, November 4, 2008, 6:57 AM Zahid Khan wrote: > > Hi, > > I am getting one failures in odbc application with 8.3 server which is > related to foreign key information. Which ODBC driver version are you using? Remember that newer drivers work with older database servers, but older drivers may not work with newer database servers. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Behavior change of FK info query
I am using 8.3.1 driver ,Is this changed in any new version ? --- On Tue, 11/4/08, Craig Ringer <[EMAIL PROTECTED]> wrote: From: Craig Ringer <[EMAIL PROTECTED]> Subject: Re: [BUGS] Behavior change of FK info query To: [EMAIL PROTECTED] Cc: pgsql-bugs@postgresql.org Date: Tuesday, November 4, 2008, 6:57 AM Zahid Khan wrote: > > Hi, > > I am getting one failures in odbc application with 8.3 server which is > related to foreign key information. Which ODBC driver version are you using? Remember that newer drivers work with older database servers, but older drivers may not work with newer database servers. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Behavior change of FK info query
Hi. Zahid Khan <[EMAIL PROTECTED]> writes: In my application we are getting different results in 8.2\xA0 and 8.3 servers. if we execute the query no 3 below after creating table even on psql.As psqlODBC drives executes query no 3 below to get foreign key information.if we want to reproduce this , we can executes the following queries on psql in sequence we are getting different results in 8.2\xA0 and 8.3 . 8.3 does not store any foreign-key information in pg_trigger.tgargs anymore. If psqlODBC is depending on this query then that's a psqlODBC bug. It'd be better to look at pg_constraint. Ahh, About foreign key, it will solve by 08.03.0300. http://psqlodbc.projects.postgresql.org/release.html I think that it is solvable by 4.). It seems that I did what point of that mistake. We has forgotten the information of a release.sorry. and, It seems that the test of UUID was not enough. http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/convert.c.diff?r1=1.173&r2=1.174 One more condition fell out. http://archives.postgresql.org/pgsql-odbc/2008-10/msg00010.php Furthermore, I think it good to use libpq by which 8.3.5 was released. So, it is better to pack up 08.03.0310.? to Dave and Inoue-san. What do you think? Regards, Hiroshi Saito -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Behavior change of FK info query
Zahid Khan wrote: > > > I am using 8.3.1 driver ,Is this changed in any new version ? Not as far as I know. There might be problems if you were using, say, an 8.2.x driver with an 8.3 server, though. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4509: array_cat's null behaviour is inconsistent
The following bug has been logged online:
Bug reference: 4509
Logged by: Kevin Field
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Windows Server 2003 SP2
Description:array_cat's null behaviour is inconsistent
Details:
Section 9.2 in the docs say, 'The ordinary comparison operators yield null
(signifying "unknown") when either input is null.' This applies to other
operators too. For example, the result of tacking an unknown value onto a
known one is unknown, because you don't know what exactly you just tacked
on. So
select null::text || 'hello';
...returns NULL, which makes sense. But then this
select array_cat(null::integer[], '{3}'::integer[]);
...doesn't return NULL, which it should, for consistency.
Kev
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4494: Memory leak in pg_regress.c
Zdenek Kotala wrote: > [EMAIL PROTECTED] napsal(a): >> In file src/test/regress/pg_regress.c:1112 >> >> It seems to me that variables "s" and "tmp" leak memory here if last_dot is >> false: > OK. It seems as a bug. tmp and s should be freed when strrchr fails. Also > there is not check when malloc fails. So who's gonna send the patch? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] plperl & sort
I've ran into this interesting problem.
It seems that while you can call sort() in a trusted plperl func you
cannot access $a & $b which effectively makes it useless.
I've tested this on 8.2.11, 8.3.5, and the nov 4 snapshot on ftp.postgresql.org
In all cases its on a mac with perl 5.8.8.
I also tested on Linux with 8.2.5 (yes yes, I know I need to upgrade!)
with the same results.
Is this intended behavior?
create or replace function trustedsort()
returns int
as $$
my @arr = (5, 4, 3, 2, 1);
my @sorted = sort { elog(NOTICE, "$a $b"); $a <=> $b } @arr;
return 1;
$$
language 'plperl';
create or replace function untrustedsort()
returns int
as $$
my @arr = (5, 4, 3, 2, 1);
my @sorted = sort { elog(NOTICE, "$a $b"); $a <=> $b } @arr;
return 1;
$$
language 'plperlu';
select trustedsort();
select untrustedsort();
drop function trustedsort();
drop function untrustedsort();
CREATE FUNCTION
CREATE FUNCTION
psql:stupid_plperl.sql:28: NOTICE:
psql:stupid_plperl.sql:28: NOTICE:
psql:stupid_plperl.sql:28: NOTICE:
psql:stupid_plperl.sql:28: NOTICE:
psql:stupid_plperl.sql:28: NOTICE:
psql:stupid_plperl.sql:28: NOTICE:
psql:stupid_plperl.sql:28: NOTICE:
psql:stupid_plperl.sql:28: NOTICE:
trustedsort
-
1
(1 row)
psql:stupid_plperl.sql:29: NOTICE: 5 4
psql:stupid_plperl.sql:29: NOTICE: 3 2
psql:stupid_plperl.sql:29: NOTICE: 4 2
psql:stupid_plperl.sql:29: NOTICE: 4 3
psql:stupid_plperl.sql:29: NOTICE: 2 1
untrustedsort
---
1
(1 row)
DROP FUNCTION
DROP FUNCTION
--
Jeff Trout <[EMAIL PROTECTED]>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
Jeff <[EMAIL PROTECTED]> writes: > I've ran into this interesting problem. > It seems that while you can call sort() in a trusted plperl func you > cannot access $a & $b which effectively makes it useless. > I've tested this on 8.2.11, 8.3.5, and the nov 4 snapshot on > ftp.postgresql.org > In all cases its on a mac with perl 5.8.8. I can confirm this behavior with perl 5.10 on Fedora 9. I suppose the Safe module is somehow blocking the variable accesses, but if so why doesn't it throw an outright error? Is this a Safe bug, or are we failing to enable something we should, or perhaps it's actually necessary to block this for security reasons?? Requires more perl-fu than I have, unfortunately. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Behavior change of FK info query
Hi,
I am getting one failures in odbc application with 8.3 server which is related
to foreign key information.
In my application we are getting different results in 8.2 and 8.3 servers. if
we execute the query no 3 below after creating table even on psql.As psqlODBC
drives executes query no 3 below to get foreign key information.if we want to
reproduce this , we can executes the following queries on psql in sequence we
are getting different results in 8.2 and 8.3 .
1 .Create table dept321.
query_string [CREATE TABLE dept321(deptno CHAR(3) NOT NULL PRIMARY KEY,
deptname VARCHAR(32))]
2 .Create table emp321.
query_string [CREATE TABLE emp321(empno CHAR(7) NOT NULL PRIMARY KEY, deptno
CHAR(3) NOT NULL, sex CHAR(1), salary DECIMAL(7,2), CONSTRAINT check1 CHECK(sex
IN('M', 'F')), CONSTRAINT check2 CHECK(salary < 7.00), CONSTRAINT fk1
FOREIGN KEY (deptno) REFERENCES dept321(deptno));]
3. Query to extract information from catalog in psqlODBC.
query_string [SELECT pt.tgargs, pt.tgnargs, pt.tgdeferrable,
pt.tginitdeferred, pp1.proname, pp2.proname, pc.oid,
pc1.oid, pc1.relname, pt.tgconstrname, pn1.nspname FROM
pg_catalog.pg_class pc, pg_catalog.pg_class pc1,
pg_catalog.pg_proc pp, pg_catalog.pg_proc pp1, pg_catalog.pg_proc
pp2, pg_catalog.pg_trigger pt, pg_catalog.pg_trigger pt1,
pg_catalog.pg_trigger pt2, pg_catalog.pg_namespace pn,
pg_catalog.pg_namespace pn1 WHERE pc.relname='dept321'AND pn.nspname =
'public' AND pc.relnamespace = pn.oid AND pt.tgconstrrelid = pc.oid
AND pp.oid = pt.tgfoid AND pp.proname Like '%ins' AND pt1.tgconstrname =
pt.tgconstrname AND pt1.tgconstrrelid = pt.tgrelid AND pt1.tgrelid =
pc.oid AND
pc1.oid = pt.tgrelid AND pp1.oid = pt1.tgfoid AND pp1.proname
like '%upd' AND (pp1.proname not like '%check%') AND pt2.tgconstrname =
pt.tgconstrname AND pt2.tgconstrrelid = pt.tgrelid AND pt2.tgrelid =
pc.oid AND pp2.oid = pt2.tgfoid AND pp2.proname Like '%del'
AND pn1.oid = pc1.relnamespace order by pt.tgconstrname]
Result of query no 3 on 8.3 server
tgargs | tgnargs | tgdeferrable | tginitdeferred | proname
| proname | oid | oid | relname | tgconstrname | nspname
+-+--++--+--+---+---+-+--+-
| 0 | f | f | RI_FKey_noaction_upd |
RI_FKey_noaction_del | 44506 | 50258 | emp321 | fk1 | public
Result of query no 3 on 8.2 server
tgargs | tgnargs | tgdeferrable | tginitdeferred
| proname | proname | oid | oid | relname |
tgconstrname | nspname
-+-+--++--+--+---+---+-+--+-
fk1\000emp321\000dept321\000UNSPECIFIED\000deptno\000deptno\000 | 6 |
f | f | RI_FKey_noaction_upd | RI_FKey_noaction_del |
66289 | 66315 | emp321 | fk1 | public
Note:- values tgargs | tgnargs are different in 8.2 and 8.3 server.psqlODBC
driver expect the values of these columns and checks the number of arguments
from 'tgnargs' column.and extracts the foreign key name from the 'tgargs'
column.
I have tried to investigate the behavior of this on server side.I can see the
code which adds the tgargs column data separated by '\\000' in CreateTrigger()
in src/backend/commands/trigger.c file.That code is available in 8.3 server as
well. That code path was being executed in 8.2 but is not being executed in
8.3.Is this intentional?, coz my odbc application is break due to this change.
Thanks,
Zahid K.
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 09:02, Jeff <[EMAIL PROTECTED]> wrote:
> I've ran into this interesting problem.
> It seems that while you can call sort() in a trusted plperl func you cannot
> access $a & $b which effectively makes it useless.
Hrm works for me if I take out the elog from sort()
create or replace function trustedsort()
returns int
as $$
my @arr = qw(5 4 3 2 1);
my @sorted = sort { $a <=> $b } @arr;
elog(NOTICE, join(' ', @sorted));
return 1;
$$
language 'plperl';
SELECT trustedsort();
NOTICE: 1 2 3 4 5
trustedsort
-
1
(1 row)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Hrm works for me if I take out the elog from sort()
Even more interesting, this variant *doesn't* work:
regression=# create or replace function trustedsort()
returns int
as $$
my @arr = qw(5 4 3 2 1);
my @sorted = sort { "$a" <=> "$b" } @arr;
elog(NOTICE, join(' ', @sorted));
return 1;
$$
language 'plperl';
CREATE FUNCTION
regression=# select trustedsort();
NOTICE: 5 4 3 2 1
trustedsort
-
1
(1 row)
Seems like it's the interpolation into a string that is failing.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Behavior change of FK info query
2008/11/4 Hiroshi Saito <[EMAIL PROTECTED]>: > Furthermore, I think it good to use libpq by which 8.3.5 was released. > So, it is better to pack up 08.03.0310.? > > to Dave and Inoue-san. > What do you think? 08.03.0400 sounds better to me. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 12:39, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Hrm works for me if I take out the elog from sort()
>
> Even more interesting, this variant *doesn't* work:
>
> regression=# create or replace function trustedsort()
> returns int
> as $$
> my @arr = qw(5 4 3 2 1);
> my @sorted = sort { "$a" <=> "$b" } @arr;
> elog(NOTICE, join(' ', @sorted));
> return 1;
> $$
> language 'plperl';
> CREATE FUNCTION
> regression=# select trustedsort();
> NOTICE: 5 4 3 2 1
> trustedsort
> -
> 1
> (1 row)
>
> Seems like it's the interpolation into a string that is failing.
It has something to do with anon subs not sure what...
see below test case
This works:
require Safe;
my $safe = Safe->new('PLPerl');
$safe->permit_only(':default');
$safe->permit(qw(sort));
$safe->share(qw(&j));
sub j
{
print "j called ". (shift) . "\n";
}
my $f = $safe->reval(<<'z');
sub blah {
my @c = sort { j("$a $b"); $a <=> $b } qw(5 4 3 2 1);
j(join(" ", @c));
return;
}
blah();
z
$ perl tsafe.pl
j called 5 4
j called 3 2
j called 4 2
j called 4 3
j called 2 1
j called 1 2 3 4 5
This fails: (which is what we do in plperl.c)
my $f = $safe->reval(<<'z');
sub {
my @c = sort { j("$a $b"); $a <=> $b } qw(5 4 3 2 1);
j(join(" ", @c));
return;
}
z
$f->();
$ perl tsafe.pl
j called
j called
j called
j called
j called
j called
j called
j called
j called 5 4 3 2 1
This works:
$safe->reval(<<'z');
my @c = sort { j("$a $b"); $a <=> $b } qw(5 4 3 2 1);
j(join(" ", @c));
return;
z
$ perl tsafe.pl
j called 5 4
j called 3 2
j called 4 2
j called 4 3
j called 2 1
j called 1 2 3 4 5
Dunno...
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 12:43, Alex Hunsaker <[EMAIL PROTECTED]> 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?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Nov 4, 2008, at 2:27 PM, Alex Hunsaker wrote: On Tue, Nov 4, 2008 at 09:02, Jeff <[EMAIL PROTECTED]> wrote: I've ran into this interesting problem. It seems that while you can call sort() in a trusted plperl func you cannot access $a & $b which effectively makes it useless. Hrm works for me if I take out the elog from sort() I came across this because I was attempting to sort some data (an array of hashrefs) in to reverse order and got very odd results.. some elogging showed $a and $b were not what they should have been and after more and more digging I was able to widdle it down to the simple case I posted. When I tried having it call a sub instead of an anonymous block it would complain the sub didn't exist. (I have other plperl functions that have subs declared and they all work fine, but I never used them with sort before). I'll have some more time to tinker with it tomorrow. I'm reasonably sure its got something to do with the Safe module and some magic-fu we may need. Looking at plperl we do allow sort so I'm not sure why $a & $b disappear.. -- Jeff Trout <[EMAIL PROTECTED]> http://www.stuarthamm.net/ http://www.dellsmartexitin.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Behavior change of FK info query
Zahid Khan <[EMAIL PROTECTED]> writes: > In my application we are getting different results in 8.2 and 8.3 servers. > if we execute the query no 3 below after creating table even on psql.As > psqlODBC drives executes query no 3 below to get foreign key information.if > we want to reproduce this , we can executes the following queries on psql in > sequence we are getting different results in 8.2 and 8.3 . 8.3 does not store any foreign-key information in pg_trigger.tgargs anymore. If psqlODBC is depending on this query then that's a psqlODBC bug. It'd be better to look at pg_constraint. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
Alex Hunsaker wrote:
On Tue, Nov 4, 2008 at 12:43, Alex Hunsaker <[EMAIL PROTECTED]> 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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> We need to document that, and given that this exists I think we don't need
> to backpatch old versions.
Agreed.
> 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.
Well its not just sort its anything that uses main:: right?
>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.
Oh defiantly :) just tossing out ideas. Instead of storing the sub we
could just call Safe::reval() everytime... that seems the safest way
to me.
The other idea Ive been toying this is instead of calling reval we can
just call Opcode::_safe_call_sv() something like the below:
I verified it on perl 5.10.0 only but I looked at 5.8.8 and those
routines in Safe.pm are the same so it should be relatively safe...
Note this is *exactly* what reval does except we already do our own
strict import. and it only works for CODE refs.
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
***
*** 283,295 _PG_init(void)
"&_plperl_to_pg_array " \
"&DEBUG &LOG &INFO &NOTICE &WARNING &ERROR %_SHARED ]);" \
"sub ::mksafefunc {" \
! " my $ret = $PLContainer->reval(qq[sub { $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; }" \
"$PLContainer->permit(qw[require caller]); $PLContainer->reval('use
strict;');" \
"$PLContainer->deny(qw[require caller]); " \
"sub ::mk_strict_safefunc {" \
! " my $ret = $PLContainer->reval(qq[sub { BEGIN {
strict->import(); } $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; }"
#define SAFE_BAD \
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');" \
--- 283,299
"&_plperl_to_pg_array " \
"&DEBUG &LOG &INFO &NOTICE &WARNING &ERROR %_SHARED ]);" \
"sub ::mksafefunc {" \
! " my $__ExPr__ = $PLContainer->reval(qq[sub { $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; " \
! " my $sub = eval 'package '. $PLContainer->{Root} .'; sub {
@_=(); $__ExPr__->(); }'; " \
! " return sub { Opcode::_safe_call_sv($PLContainer->{Root},
$PLContainer->{Mask}, $sub); }; } "\
"$PLContainer->permit(qw[require caller]); $PLContainer->reval('use
strict;');" \
"$PLContainer->deny(qw[require caller]); " \
"sub ::mk_strict_safefunc {" \
! " my $__ExPr__ = $PLContainer->reval(qq[sub { BEGIN {
strict->import(); } $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; "\
! " my $sub = eval 'package '. $PLContainer->{Root} .'; sub {
@_=(); $__ExPr__->(); }'; " \
! " return sub { Opcode::_safe_call_sv($PLContainer->{Root},
$PLContainer->{Mask}, $sub); }; }"
#define SAFE_BAD \
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');" \
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote: > The other idea Ive been toying this is instead of calling reval we can > just call Opcode::_safe_call_sv() something like the below: Argh gmail probably ate the whitespace in the patch... see attached plperl_safe.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
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.
>
> Well its not just sort its anything that uses main:: right?
Err no you're right its only builtins that use main:: sort being the
only one I know of off the top of my head... its a shame
PLContainer->share('$main::a'); does not seem to work..
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
Alex Hunsaker wrote:
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
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.
Well its not just sort its anything that uses main:: right?
Err no you're right its only builtins that use main:: sort being the
only one I know of off the top of my head... its a shame
PLContainer->share('$main::a'); does not seem to work..
$a and $b are magical *package* variables. See "perldoc perlvar". This
has nothing whatever to do with main::
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 15:17, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Alex Hunsaker wrote:
>> Err no you're right its only builtins that use main:: sort being the
>> only one I know of off the top of my head... its a shame
>> PLContainer->share('$main::a'); does not seem to work..
>>
>
>
> $a and $b are magical *package* variables. See "perldoc perlvar". This has
> nothing whatever to do with main::
Hah right! The perl is strong in this one! =)
I was just remember seeing warnings from typos like:
$ perl -We '$a = $b;'
Name "main::a" used only once: possible typo at -e line 1.
Name "main::b" used only once: possible typo at -e line 1.
... but that's neither here nor there
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
Tom Lane wrote:
Jeff <[EMAIL PROTECTED]> writes:
I've ran into this interesting problem.
It seems that while you can call sort() in a trusted plperl func you
cannot access $a & $b which effectively makes it useless.
I've tested this on 8.2.11, 8.3.5, and the nov 4 snapshot on ftp.postgresql.org
In all cases its on a mac with perl 5.8.8.
I can confirm this behavior with perl 5.10 on Fedora 9. I suppose the
Safe module is somehow blocking the variable accesses, but if so why
doesn't it throw an outright error? Is this a Safe bug, or are we
failing to enable something we should, or perhaps it's actually
necessary to block this for security reasons?? Requires more perl-fu
than I have, unfortunately.
Completely untested speculation based on my knowledge of perl and
a bit of reading:
The reason you can't see $a and $b is that sort internally sets
these variables in the main package. That is, sort is setting
$main::a and $main::b, and when you run the plperl code in the
safe compartment, main:: isn't visible any more.
The reason you don't get an error is that unadorned $a and $b
which you reference in the sort routine is relative to the
namespace you give to Safe. That is, your sort sub is trying
to access $PLPerl::a and $PLPerl::b which isn't what is
set by sort.
It looks like there are two fixes that should work, one sort based
and one Safe based.
sort based: use a subroutine with a prototype. From perldoc -f sort:
If the subroutine’s prototype is "($$)", the elements to be
compared are passed by reference in @_, as for a normal
subroutine.
Safe based: share the $a and $b variables with the compartment.
$compartment->share_from('main', '$a', '$b');
I'm not sure how postgres embeds perl. Depending on how the
interpreters are set up, it is conceivable that the contents
of $a and $b could be leaked to other "threads" or similar that
are using the same interpreter. In any case, using the
share_from() method of Safe would have to be changed at
the postgres level rather than the untrusted language
function writer's level.
I can do some testing if anyone needs something more than
the above suggestions.
--
nw
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
