Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Inconsistent syntax in GRANT

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-21 02:18:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Updated patch applied.  I decided Tom was right to just ignore invalid
sequence permission from pre-8.2 databases, rather than try to use GRANT
TABLE;  there was no reason to do it and avoiding it made the code
cleaner and more robust.

The changes were:

Add GRANT ON SEQUENCE syntax to support sequence-only permissions.
Continue to support GRANT ON [TABLE] for sequences for backward
compatibility;  issue warning for invalid sequence permissions.

[ Backward compatibility warning message.]

Add USAGE permission for sequences that allows only currval() and
nextval(), not setval().

Mention object name in grant/revoke warnings because of possible
multi-object operations.


Bruce Momjian wrote:
> 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);
> 	test=> CREATE SEQUENCE seq;
> 	test=> GRANT ALL ON seq, tab TO PUBLIC;
> 	test=> REVOKE USAGE ON seq, tab FROM PUBLIC;
> 	ERROR:  invalid privilege type USAGE for table
> 	test=> REVOKE SELECT ON seq, tab FROM PUBLIC;
> 	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"
> and pg_dump has:
> 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                        |
  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

In response to

pgsql-hackers by date

Next:From: Alfranio Correia JuniorDate: 2006-01-21 02:21:43
Subject: strange locks
Previous:From: Alfranio Correia JuniorDate: 2006-01-21 01:54:44
Subject: strange behavior on locks

pgsql-patches by date

Next:From: Jaime CasanovaDate: 2006-01-21 17:58:13
Subject: BUG #2195: log_min_messages crash server when in DEBUG3 to 5
Previous:From: Andrew DunstanDate: 2006-01-21 01:16:08
Subject: plperl / locale / win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group