Thread: Sequence privileges

The documentation of the sequence privileges on the GRANT reference page
doesn't match the code.

Documented:

currval:    UPDATE
nextval:    UPDATE
setval:        UPDATE

Actual:

currval:    SELECT
nextval:    UPDATE
setval:        UPDATE

But shouldn't it more ideally be

currval:    SELECT
nextval:    SELECT + UPDATE
setval:        UPDATE

because nextval allows you to infer the content of the sequence?  (Cf.
UPDATE tab1 SET a = b requires SELECT + UPDATE on tab1.)

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> But shouldn't it more ideally be

> currval:    SELECT
> nextval:    SELECT + UPDATE
> setval:    UPDATE

> because nextval allows you to infer the content of the sequence?  (Cf.
> UPDATE tab1 SET a = b requires SELECT + UPDATE on tab1.)

One objection is that testing for both privs will require two aclcheck
calls (since aclcheck(SELECT|UPDATE) will check for the OR not the AND
of the privileges).  Not sure it's worth the overhead.

Given that nextval() is really the only interesting operation on
sequences (you cannot do a real UPDATE), I don't see a problem with
interpreting "UPDATE" as "the right to do nextval()" for sequences.

Since currval only returns to you the result of your own prior nextval,
there is no real point in giving it a different privilege bit.
Accordingly I think it *should* be testing UPDATE --- the docs are right
and the code is wrong.  (If it weren't for your recent addition of
setuid functions, I'd question why currval bothers to make a privilege
test at all.)

"SELECT" still means what it says: the ability to do a select from
the sequence, which lets you see the sequence parameters.  So what
we really have is:
SELECT: read sequence as a tableUPDATE: all sequence-specific operations.

You could maybe make an argument that setval() should have a different
privilege than nextval(), but otherwise this seems sufficient to me.

There is now room in ACL to invent a couple of sequence-specific
privilege bits if it bothers you to use "UPDATE" for the can-invoke-
sequence-functions privilege, but I'm not sure it's worth creating
a compatibility issue just to do that.
        regards, tom lane

Tom Lane wrote:
> 
> "SELECT" still means what it says: the ability to do a select from
> the sequence, which lets you see the sequence parameters.  So what
> we really have is:
> 
>     SELECT: read sequence as a table
>     UPDATE: all sequence-specific operations.
> 

Since the sequence-specific operations are really just function calls, 
maybe it should be:SELECT:  read sequence as a tableEXECUTE: all sequence-specific operations.

Joe

Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> what we really have is:
>> 
>> SELECT: read sequence as a table
>> UPDATE: all sequence-specific operations.

> Since the sequence-specific operations are really just function calls, 
> maybe it should be:
>     SELECT:  read sequence as a table
>     EXECUTE: all sequence-specific operations.

But is it worth creating a compatibility problem for?  Existing pg_dump
scripts are likely to GRANT UPDATE.  They certainly won't say GRANT
EXECUTE since that doesn't even exist in current releases.

I agree that EXECUTE (or some sequence-specific permission name we might
think of instead) would be logically cleaner, but I don't think it's
worth the trouble of coming up with a compatibility workaround.  UPDATE
doesn't seem unreasonably far off the mark.
        regards, tom lane

On Sat, 18 May 2002 19:45:30 -0400
"Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Joe Conway <mail@joeconway.com> writes:
> > Since the sequence-specific operations are really just function calls, 
> > maybe it should be:
> >     SELECT:  read sequence as a table
> >     EXECUTE: all sequence-specific operations.
> 
> But is it worth creating a compatibility problem for?  Existing pg_dump
> scripts are likely to GRANT UPDATE.  They certainly won't say GRANT
> EXECUTE since that doesn't even exist in current releases.
> 
> I agree that EXECUTE (or some sequence-specific permission name we might
> think of instead) would be logically cleaner, but I don't think it's
> worth the trouble of coming up with a compatibility workaround.

Well, one possible compatibility workaround would be trivial -- we could
hack GRANT so that doing GRANT UPDATE on sequence relations is
translated into GRANT EXECUTE.

As for whether it's worth the bother, I'm not sure -- neither
solution strikes me as particularly clean.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC