[BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
The following bug has been logged online: Bug reference: 5334 Logged by: Tim Bunce Email address: tim.bu...@pobox.com PostgreSQL version: 8.4.2 Operating system: OS X Description:Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4 Details: Version 2.22 of the Perl Safe module breaks PostgreSQL 8.4 (and probably earlier versions) that have a default encoding of UTF-8. Safe 2.2x added extra security for closures created inside Safe but then returned and executed from outside Safe (which is what PostgreSQL does). These closures are now wrapped so that they are executed with Safe restrictions in effect. This extra security is causing the 'utf8fix' code in PostgreSQL 8.4 to die (with the error "'require' trapped by operation mask"). I'm investigating this currently but don't yet have a complete fix. (The immediate problem appears to be easily fixed by switching to the simpler utf8fix code I added for PostgreSQL 9.0. But a failure still happens if warn() is called with utf8 string.) -- 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 #5335: GUC value lost on exception
The following bug has been logged online: Bug reference: 5335 Logged by: Tim Bunce Email address: tim.bu...@pobox.com PostgreSQL version: 8.4.2 Operating system: OS X Description:GUC value lost on exception Details: andrew=# SET SESSION plperl.use_strict = on; SET andrew=# SHOW plperl.use_strict; plperl.use_strict --- on (1 row) andrew=# DO $$ elog(ERROR,"error") $$ language plperl; ERROR: error at line 1. CONTEXT: PL/Perl anonymous code block andrew=# SHOW plperl.use_strict; plperl.use_strict --- off (1 row) See http://archives.postgresql.org/message-id/4b4fb92d.5040...@dunslane.net and the thread following it. See also http://archives.postgresql.org/message-id/4b577e9f.8000...@dunslane.net -- 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 #5333: psql returns 0 on error
The following bug has been logged online: Bug reference: 5333 Logged by: Email address: pekka.jarvi...@gmail.com PostgreSQL version: 8.4 Operating system: Ubuntu Karmic Koala Description:psql returns 0 on error Details: $ psql -U foo -h 127.0.0.1 -f doesntwork.sql db Password for user foo: ERROR: invalid byte sequence for encoding "UTF8": 0xe46976 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". $ echo $? 0 return value should be something else than 0. doesntwork.sql just have contain something that doesn't 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] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
On Thu, Feb 18, 2010 at 10:50:23AM +, Tim Bunce wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5334
> Logged by: Tim Bunce
> Email address: tim.bu...@pobox.com
> PostgreSQL version: 8.4.2
> Operating system: OS X
> Description:Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL
> 8.4
> Details:
>
> Version 2.22 of the Perl Safe module breaks PostgreSQL 8.4 (and probably
> earlier versions) that have a default encoding of UTF-8.
>
> Safe 2.2x added extra security for closures created inside Safe but then
> returned and executed from outside Safe (which is what PostgreSQL does).
> These closures are now wrapped so that they are executed with Safe
> restrictions in effect.
>
> This extra security is causing the 'utf8fix' code in PostgreSQL 8.4 to die
> (with the error "'require' trapped by operation mask").
>
> I'm investigating this currently but don't yet have a complete fix. (The
> immediate problem appears to be easily fixed by switching to the simpler
> utf8fix code I added for PostgreSQL 9.0. But a failure still happens if
> warn() is called with utf8 string.)
It took a depressingly large number of intense hours to work out what
was going on and then more to try to work out a relatively clean solution.
The underlying problem is in perl and Safe but sadly there's no
reasonable way to fix Safe such that PostgreSQL would work without
changes.
The attached patch (over REL8_4_STABLE) works around the problem.
The key line is:
*PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
This allows the perl regex logic to call the SWASHNEW method that's
called when information from the Unicode character database is needed.
(The lack of that method was causing the regex logic to think that the
utf8 module wasn't loaded, so it would try to 'require' it but fail due
to the restrictions of the Safe compartment.)
The rest of the patch is updates the surrounding code to the same
simplified 'utf8fix' logic used in PostgreSQL 9.0, and the same Safe
version checks.
Tim.
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index 73da04c..356ee42 100644
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
*** static SV **hv_store_string(HV *hv, cons
*** 162,167
--- 162,168
static SV **hv_fetch_string(HV *hv, const char *key);
static SV *plperl_create_sub(char *proname, char *s, bool trusted);
static SV *plperl_call_perl_func(plperl_proc_desc *desc, FunctionCallInfo fcinfo);
+ static char *strip_trailing_ws(const char *msg);
/*
* This routine is a crock, and so is everyplace that calls it. The problem
*** plperl_init_interp(void)
*** 528,549
static void
plperl_safe_init(void)
{
! SV *res;
! double safe_version;
!
! res = eval_pv(SAFE_MODULE, FALSE); /* TRUE = croak if failure */
! safe_version = SvNV(res);
/*
! * We actually want to reject safe_version < 2.09, but it's risky to
! * assume that floating-point comparisons are exact, so use a slightly
! * smaller comparison value.
*/
! if (safe_version < 2.0899)
{
/* not safe, so disallow all trusted funcs */
eval_pv(SAFE_BAD, FALSE);
}
else
{
--- 529,557
static void
plperl_safe_init(void)
{
! SV *safe_version_sv;
! IV safe_version_x100;
! safe_version_sv = eval_pv(SAFE_MODULE, FALSE); /* TRUE = croak if failure */
! safe_version_x100 = (int)(SvNV(safe_version_sv) * 100);
/*
! * Reject too-old versions of Safe and some others:
! * 2.20: http://rt.perl.org/rt3/Ticket/Display.html?id=72068
! * 2.21: http://rt.perl.org/rt3/Ticket/Display.html?id=72700
*/
! if (safe_version_x100 < 209 || safe_version_x100 == 220 || safe_version_x100 == 221)
{
/* not safe, so disallow all trusted funcs */
eval_pv(SAFE_BAD, FALSE);
+ if (SvTRUE(ERRSV))
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_INTERNAL_ERROR),
+ errmsg("while executing PLC_SAFE_BAD"),
+ errdetail("%s", strip_trailing_ws(SvPV_nolen(ERRSV))) ));
+ }
+
}
else
{
*** plperl_safe_init(void)
*** 551,585
if (GetDatabaseEncoding() == PG_UTF8)
{
/*
! * Fill in just enough information to set up this perl function in
! * the safe container and call it. For some reason not entirely
! * clear, it prevents errors that can arise from the regex code
! * later trying to load utf8 modules.
! */
! plperl_proc_desc desc;
! FunctionCallInfoData fcinfo;
! SV *ret;
! SV *func;
!
! /* make sure we don't call ourselves recursively */
! plperl_safe_init_done = true;
!
! /* compile the function */
! func = plperl_create_sub("utf8fix",
! "return shift =~ /\\xa9/i ? 'true' : 'false' ;",
! true);
!
! /* set up to call the function with a single text argument 'a' */
! desc.reference = func;
! desc.nargs = 1;
! desc.arg_is_rowtype[0] = false;
! fmgr_info(F_TEXTOUT, &(desc.arg_out_
Re: [BUGS] BUG #5333: psql returns 0 on error
On Thu, Feb 18, 2010 at 02:20, wrote: > $ psql -U foo -h 127.0.0.1 -f doesntwork.sql db > Password for user foo: > ERROR: invalid byte sequence for encoding "UTF8": 0xe46976 > HINT: This error can also happen if the byte sequence does not match the > encoding expected by the server, which is controlled by "client_encoding". > $ echo $? > 0 You probably want to define ON_ERROR_STOP... see the man page about it. psql -v 'ON_ERROR_STOP=on' ... -- 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 #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> The key line is:
>
> *PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
Hrm... It seems to work for me in HEAD and AFAICS we dont have that
line. Did I just miss it? Or did you happen to fix it in another way
with your refactoring?
Another Idea that comes to mind would be instead of (in ::mksafefunc):
my $subref = ->reval(sub {} );
$subref->();
do:
my $subref = ->reval(sub {});
return sub { ->reval("$subreb->();"); }
or something...
I did a few quick tests but it failed miserably for me... Im also not
fond of adding yet another closure. :)
> This allows the perl regex logic to call the SWASHNEW method that's
> called when information from the Unicode character database is needed.
> (The lack of that method was causing the regex logic to think that the
> utf8 module wasn't loaded, so it would try to 'require' it but fail due
> to the restrictions of the Safe compartment.)
Makes me think we might just be able to share some of utf8 package in the safe?
> The rest of the patch is updates the surrounding code to the same
> simplified 'utf8fix' logic used in PostgreSQL 9.0, and the same Safe
> version checks.
From a quick look it looks ok.
--
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 #5250: Tutorial examples(pre-compiled) not present with precompiled binary version of PostgreSQL.
Dave Page wrote: > On Tue, Dec 22, 2009 at 8:43 PM, Ashish Anand > wrote: > > Alvaro, Please read the?first?three mails in this thread. > > > > Dave, can you open a bug at your end. Just open it so that it can be tracked > > two months down the line. I am not insisting on fixing it right now. > > There is nothing to fix at 'my end' at the moment (whichever end you > consider that to be). As has been established in the later messages in > the thread, the tutorial isn't built at all by the PostgreSQL MSVC > build system, and on other platforms the installation location is > fixed. As Tom as pointed out, we first need to determine we want it to > work, and then apply the appropriate fix to PostgreSQL. Only then will > the downstream packages make any changes, should they be required. > > My vote is to reword the docs so they don't say that binary distros > will include the pre-built tutorial binaries, and then we can consider > shipping the source files in the installers/rpms etc. I have applied the attached patch which removes the mention that the tutorial files are precompiled. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/query.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/query.sgml,v retrieving revision 1.53 diff -c -c -r1.53 query.sgml *** doc/src/sgml/query.sgml 17 Jun 2009 21:58:49 - 1.53 --- doc/src/sgml/query.sgml 19 Feb 2010 01:14:45 - *** *** 26,32 Examples in this manual can also be found in the PostgreSQL source distribution ! in the directory src/tutorial/. To use those files, first change to that directory and run make: --- 26,34 Examples in this manual can also be found in the PostgreSQL source distribution ! in the directory src/tutorial/. (Binary ! distributions of PostgreSQL might not ! compile these files.) To use those files, first change to that directory and run make: *** *** 35,46 This creates the scripts and compiles the C files containing user-defined ! functions and types. (If you installed a pre-packaged version of ! PostgreSQL rather than building from source, ! look for a directory named tutorial within the ! PostgreSQL distribution. The make ! part should already have been done for you.) ! Then, to start the tutorial, do the following: $ cd /tutorial --- 37,43 This creates the scripts and compiles the C files containing user-defined ! functions and types. Then, to start the tutorial, do the following: $ cd /tutorial -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
