restore error - language "plperlu" is not trusted

[Christopher Murtagh]

Greetings,

I just had to dump and restore one of my DBs (7.4RC2), and I got an
interesting message.

I first did:

pg_dump dbname > db_restore.sql

Then at console did the following:

\i db_restpre.sql

which performed everything as expected with the following ERROR
message:

ERROR: language "plperlu" is not trusted

and it gave a line number, which contained the following:

GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;

Now, my plperlu functions seem to behaving as expected (they read from
and write to /tmp). Should I be worried?

Cheers,

Chris

--
Christopher Murtagh
Enterprise Systems Administrator
ISR / Web Communications Group
McGill University
Montreal, Quebec
Canada

Tel.: [phone]
Fax: [phone]

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[scott.marlowe]

On 17 Dec 2003, Christopher Murtagh wrote:

Greetings,

I just had to dump and restore one of my DBs (7.4RC2), and I got an
interesting message.

I first did:

pg_dump dbname > db_restore.sql

Then at console did the following:

\i db_restpre.sql

which performed everything as expected with the following ERROR
message:

ERROR: language "plperlu" is not trusted

and it gave a line number, which contained the following:

GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;

Now, my plperlu functions seem to behaving as expected (they read from
and write to /tmp). Should I be worried?

Did you install plperlu ahead of time as the super user, then run your
restore as the regular database owner?
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Christopher Murtagh]

On Wed, 2003-12-17 at 10:55, scott.marlowe wrote:

which performed everything as expected with the following ERROR
message:

ERROR: language "plperlu" is not trusted

and it gave a line number, which contained the following:

GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;

Now, my plperlu functions seem to behaving as expected (they read from
and write to /tmp). Should I be worried?

Did you install plperlu ahead of time as the super user, then run your
restore as the regular database owner?

No, I hadn't, I guess I had assumed that the restore would do that.
More interestingly, I did the restore on a different
machine/architecture (PPC instead of Intel) running 7.4 final release
(instead of RC2) and I didn't get the error message. However all of my
plperlu triggers seem to behaving normally. When I tried to install
plperlu afterwards I got this:

createlang plperlu a
createlang: language "plperlu" is already installed in database "a"

Hrm... Ah well. I'll know for next time to install the language first,
I just hope it won't bit me in the ass before then. :-)

Cheers,

Chris

--
Christopher Murtagh
Enterprise Systems Administrator
ISR / Web Communications Group
McGill University
Montreal, Quebec
Canada

Tel.: [phone]
Fax: [phone]

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Christopher Murtagh <ch*****************@mcgill.ca> writes:

[ pg_dump script failed with ]
ERROR: language "plperlu" is not trusted
and it gave a line number, which contained the following:
GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;

Hm. The backend flat-out rejects all attempts at GRANT on untrusted
languages, even if you are superuser and the grantee is too. I'm not
totally sure about the rationale for that (Peter?) but in any case
pg_dump has evidently not gotten the word. If we think the backend's
behavior is right then we'd better change pg_dump to suppress trying
to GRANT permissions on untrusted languages.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Peter Eisentraut]

Tom Lane wrote:

Hm. The backend flat-out rejects all attempts at GRANT on untrusted
languages, even if you are superuser and the grantee is too. I'm not
totally sure about the rationale for that (Peter?)
Why would you need it? It's only going to create fuss about useless
functionality.
but in any case
pg_dump has evidently not gotten the word. If we think the backend's
behavior is right then we'd better change pg_dump to suppress trying
to GRANT permissions on untrusted languages.

There should not be any permissions, so there should be nothing to dump.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Tom Lane]

Peter Eisentraut <pe*****@gmx.net> writes:

Tom Lane wrote:

pg_dump has evidently not gotten the word. If we think the backend's
behavior is right then we'd better change pg_dump to suppress trying
to GRANT permissions on untrusted languages.

There should not be any permissions, so there should be nothing to dump.

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).

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Peter Eisentraut]

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.
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.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Tom Lane]

Peter Eisentraut <pe*****@gmx.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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org