Re: [HACKERS] Inconsistent syntax in GRANT

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Bruno Wolff III <bruno(at)wolff(dot)to>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Inconsistent syntax in GRANT
Date: 2006-01-11 22:53:00
Message-ID: 200601112253.k0BMr0i26727@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> Just ignore the inapplicable permissions during pg_dump. I think you're
> >> making this harder than it needs to be...
>
> > check all permission bits
> > call object-type-specific routine
> > loop over each object and set permission bits
>
> > so, to fix this, I would need to move the permission bit checks into
> > object-type-specific routines so that I could check the permission bits
> > for each object, rather than once in a single place.
>
> You'd have to allow the union of relation and sequence rights during the
> conversion to bitmask form in ExecuteGrantStmt, and then check more
> closely inside the per-object loop in ExecGrant_Relation, but that
> doesn't seem like a showstopper to me. It certainly seems more pleasant
> than exposing bizarre restrictions to users because we're sharing code
> between the cases.

Your idea of using a union of permission bits was very helpful. I was
afraid I was going to have to loop over every permission bit again in
the table/sequence grant permission code, but the union allowed for a
very simple check in that code.

It allows for better code checks and I think it behaves as expected:

test=> CREATE TABLE tab(x INTEGER);
CREATE TABLE
test=> CREATE SEQUENCE seq;
CREATE SEQUENCE
test=> GRANT ALL ON seq, tab TO PUBLIC;
GRANT
test=> REVOKE USAGE ON seq, tab FROM PUBLIC;
ERROR: invalid privilege type USAGE for table
test=> REVOKE SELECT ON seq, tab FROM PUBLIC;
REVOKE
test=> REVOKE DELETE ON seq, tab FROM PUBLIC;
WARNING: sequence "seq" only supports USAGE, SELECT, AND UPDATE
WARNING: no privileges could be revoked for "seq"
REVOKE

and pg_dump has:

GRANT USAGE,UPDATE ON SEQUENCE x TO PUBLIC;

GRANT INSERT,RULE,UPDATE,REFERENCES,TRIGGER ON TABLE xx TO PUBLIC;

Note I had to add the object name to the warning message so it is clear
which object permission changes did succeed. I have updated the patch.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Attachment Content-Type Size
unknown_filename text/plain 29.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Qingqing Zhou 2006-01-11 23:24:02 Checkpoint question
Previous Message Tom Lane 2006-01-11 21:39:25 Re: sort operation leads planner to different number of rows?

Browse pgsql-patches by date

  From Date Subject
Next Message Scott Marlowe 2006-01-11 23:31:23 Re: Different exponent in error messages
Previous Message Tom Lane 2006-01-11 22:52:46 Re: Different exponent in error messages