Re: restore error - language "plperlu" is not trusted

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Christopher Murtagh <christopher(dot)murtagh(at)mcgill(dot)ca>, postgres general <pgsql-general(at)postgresql(dot)org>
Subject: Re: restore error - language "plperlu" is not trusted
Date: 2003-12-18 17:49:49
Message-ID: 20856.1071769789@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> Uh, no, because you can say something like
>> revoke all on language plperlu from public;
>> and end up with non-null lanacl (because it instantiates the default
>> assumption that the owner has all privileges).

> OK, that needs to be disallowed.

Fair enough. I thought it was a bit odd to disallow GRANT but allow
REVOKE anyway.

>> We could possibly hack the backend to avoid that, but I think pg_dump
>> will need the special-case test anyway since it has to be able to
>> cope with existing databases, wherein lanacl may be non-null.

> So far we know of 1 such database. I'd like to see some more before we
> bother about it.

It's a one-line addition --- just put the dumpACL call inside
"if (lanpltrusted)". I think it is a reasonable change. We'd have to
do something anyway, because the existing pg_dump code is certainly
broken for dumping untrusted languages from pre-7.3 databases (it
assumes a nonempty lanacl setting in that case).

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron St-Pierre 2003-12-18 18:19:57 Re: Function Returning SETOF Problem
Previous Message Peter Eisentraut 2003-12-18 17:38:18 Re: restore error - language "plperlu" is not trusted

Browse pgsql-patches by date

  From Date Subject
Next Message Kurt Roeckx 2003-12-18 18:25:27 Re: ISO year.
Previous Message Andrew Dunstan 2003-12-18 17:48:14 Re: replace all with * in pg_hba.conf