Re: Proposal: GRANT cascade to implicit sequences

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: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org
Subject: Re: Proposal: GRANT cascade to implicit sequences
Date: 2004-11-11 04:44:01
Message-ID: 200411110444.iAB4i1o10268@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


I looked over this thread and can't see any TODO item. Having GRANT
just propogate from the table to a SERIAL sequence doesn't work because
an INSERT into a table is an UPDATE of the sequence.

Is there a TODO here?

---------------------------------------------------------------------------

Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > I can't think of a good approach for migration of old pg_dumps though, so
> > perhaps this is more trouble than it's worth.
>
> That would probably be the major objection to any redefinition of the
> meanings of the individual sequence permissions. We could possibly
> invent a couple of brand new permission bits though, and stipulate that
> "UPDATE" incorporates them both.
>
> > Implicit sequences on the other hand can be migrated easily by ignoring all
> > explicit grants and just looking at the grants on the table.
>
> It's not really that easy. Before we hack up the permissions system like
> this I'd want to see a complete solution, which this is not, because it
> doesn't work in the context of rules. Consider
>
> CREATE TABLE t (id SERIAL ...);
>
> CREATE VIEW v AS SELECT * FROM t;
>
> CREATE RULE r AS ON INSERT TO v DO INSTEAD INSERT INTO t ...
>
> GRANT INSERT ON v TO joeuser;
>
> joeuser will be able to invoke the insertion rule, but nextval() will
> still fail because it doesn't know about the rule context --- it'll
> see joeuser as the current user, not the owner of the rule.
>
> Eventually I'd like to replace the nextval('foo') notation with a parsed
> construct foo.nextval, which is (a) Oracle compatible, (b) able to
> withstand renamings of the foo sequence, and (c) amenable to having the
> permissions check done during rangetable scanning, which would fix the
> rule problem. There is some discussion of this in the pghackers archives.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Barnard 2004-11-11 04:56:50 Re: Important Info on comp.databases.postgresql.general
Previous Message Kris Jurka 2004-11-11 04:24:56 Re: updateString error in PostgreSQL7.4 with JDBC