On 1/6/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> Marko Kreen wrote:
> > On 1/6/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> > > Bruno Wolff III wrote:
> > > > It might be nice to split nextval and currval access as well. nextval access
> > > > corresponds to INSERT and currval access to SELECT.
> > >
> > > Uh, that is already in the code. nextval()/setval() is UPDATE, and
> > > currval() is SELECT.
> >
> > This seems weird. Shouldn't nextval/currval go together and setval
> > separately?
>
> Uh, logically, yes, but practially currval just reads/SELECTs, while
> nextval modifies/UPDATEs.
Yeah, thats the mechanics behind it, but the currval() only
works if the user was already able to call nextval(), so I see
no point in separating them.
In other words: there is nothing to do with only access to currval(),
and with access to nextval() but not to currval() user loses only
in convinience.
> > Considering there's no currval() without nextval(), what point
> > is disallowing currval() when user is able to call nextval()?
>
> Not sure. I think SET SESSION AUTHORIZATION would make it possible.
/me confused, looks at docs...
Huh? I really hope you are mistaken. This would mean the sequence
state for currval() is kept per-user not per-backend. This would
make impossible to make several connections as same user. Is Postgres
really that broken?
> > I rather want to allow nextval/currval and disable setval as it
> > allows regular user to DoS the database.
>
> Oh, interesting. We could easily have INSERT control that if we wanted,
> but I think you have to make a clear use case to override the risk of
> breaking applications.
I'd turn it around: is there any use-case for setval() for regular user?
IMHO it's a admin-level operation, dangerous, and not needed for regular
work.
--
marko
