From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | 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-06 17:47:02 |
Message-ID: | e51f66da0601060947q669b86e8n83937642cab3678e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On 1/6/06, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> Marko Kreen wrote:
> > On 1/6/06, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-06 18:01:37 | Re: [HACKERS] Inconsistent syntax in GRANT |
Previous Message | Bruce Momjian | 2006-01-06 17:46:01 | Re: [HACKERS] Inconsistent syntax in GRANT |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-06 18:01:37 | Re: [HACKERS] Inconsistent syntax in GRANT |
Previous Message | Bruce Momjian | 2006-01-06 17:46:01 | Re: [HACKERS] Inconsistent syntax in GRANT |