Re: [HACKERS] BIG grant problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] BIG grant problem
Date
Msg-id 17222.911111502@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] BIG grant problem  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] BIG grant problem
Re: [HACKERS] BIG grant problem
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Terry Mackintosh wrote:
>> Minor detail, but when I did 'pg_dump -z -f dump.file dbname' and then
>> went to restore it, I found that the grant statments are like:
>> GRANT ALL on "tablename" to "tablename";
>> instead of
>> GRANT ALL on "tablename" to "username";

> Yikes, confirmed here.  We need to know how this got into the tree
> without showing up on our tests,

Well, that's easy --- there are no regression tests that test pg_dump
at all, nor any that test multiple table owners and permissions.

FWIW, pg_dump -z works correctly for GRANT to PUBLIC --- otherwise
I would've noticed some time ago.  But I hadn't had occasion
to check granting permission to specific users :-( ... and I don't
think most of the rest of the developers work with databases that
even have multiple users, let alone put access restrictions on
individual tables.

It's certainly true that pg_dump is pretty weak in the area of
table ownerships and permissions.  We have fixed several bugs
in that area since 6.3.2, and I'm not particularly surprised to
hear of another one.  We need someone who actually has occasion
to work with access-restricted databases to pound on pg_dump for
a while and flush out the bugs.  (Terry, can you volunteer?)
I don't think the bugs will be hard to fix, it's just a matter
of not having done enough testing.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Taral"
Date:
Subject: RE: [HACKERS] More PostgreSQL+CORBA
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] BIG grant problem