Re: lastval exposes information that currval does not
От | Phil Frost |
---|---|
Тема | Re: lastval exposes information that currval does not |
Дата | |
Msg-id | 20060728004956.GA8533@unununium.org обсуждение исходный текст |
Ответ на | Re: lastval exposes information that currval does not (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Jul 27, 2006 at 04:40:45PM -0400, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > What we should really do is have lastval() fail if the user does not > > have appropiate permissions on the schema. Having it not fail is a bug, > > and documenting a bug turns it not into a feature, but into a "gotcha". > > I'm unconvinced that it's either a bug or a gotcha. lastval doesn't > tell you which sequence it's giving you a value from, so I don't really > see the reasoning for claiming that there's a security hole. Also, > *at the time you did the nextval* you did have permissions. Does anyone > really think that a bad guy can't just remember the value he got? > lastval is merely a convenience. Not true. The nextval can be done as a different user (think security definer functions), and then some other user can get the value with lastval. Why does that lastval doesn't tell you what sequence it's going to use negate the security holeness of the issue? If lastval is merely a convenience, then why does it also do more than currval? Yeah, it's convenient. But it exposes more information. If it's not a bug or a gotcha, then it should be at least one of expected and documented. I would hardly say the short paragraph in the documentation describes the (weird, i think) semantics of the schema usage privilege. I would not expect to do anything to objects in a schema with no usage privilege by any method, since this the observed behavour by normal methods. And, what of the precarious of the schema usage check in general? What if someone forgets about it and writes a function that compromises something more serious -- say the last inserted row? Wouldn't it be not so great if your application's security depends on a user not being able to access some information, but an attacker notices it can be accessed in some obscure way before you do? I can definately understand if there are performance reasons, or even just a lack of urgency, but it should at least be fully documented in an obvious place in the manual.
В списке pgsql-hackers по дате отправления: