Re: [GENERAL] column-level update privs + lock table
От | Simon Riggs |
---|---|
Тема | Re: [GENERAL] column-level update privs + lock table |
Дата | |
Msg-id | 1290962113.4634.76.camel@ebony обсуждение исходный текст |
Ответ на | Re: [GENERAL] column-level update privs + lock table (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [GENERAL] column-level update privs + lock table
|
Список | pgsql-hackers |
On Fri, 2010-11-26 at 19:11 -0500, Robert Haas wrote: > 2010/11/25 KaiGai Kohei <kaigai@ak.jp.nec.com>: > > (2010/10/16 4:49), Josh Kupershmidt wrote: > >> [Moving to -hackers] > >> > >> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs<simon@2ndquadrant.com> wrote: > >>> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: > >>>> On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt<schmiddy@gmail.com> wrote: > >>>> > >>>>> I noticed that granting a user column-level update privileges doesn't > >>>>> allow that user to issue LOCK TABLE with any mode other than Access > >>>>> Share. > >>>> > >>>> Anyone think this could be added as a TODO? > >>> > >>> Seems so to me, but you raise on Hackers. > >> > >> Thanks, Simon. Attached is a simple patch to let column-level UPDATE > >> privileges allow a user to LOCK TABLE in a mode higher than Access > >> Share. Small doc. update and regression test update are included as > >> well. Feedback is welcome. > >> > > > > I checked your patch, then I'd like to mark it as "ready for committer". > > > > The point of this patch is trying to solve an incompatible behavior > > between SELECT ... FOR SHARE/UPDATE and LOCK command. > > > > On ExecCheckRTEPerms(), it allows the required accesses when no columns > > are explicitly specified in the query and the current user has necessary > > privilege on one of columns within the target relation. > > If we stand on the perspective that LOCK command should take same > > privileges with the case when we use SELECT ... FOR SHARE/UPDATE without > > specifying explicit columns, like COUNT(*), the existing LOCK command > > seems to me odd. > > > > I think this patch fixes the behavior as we expected. > > I'm not totally convinced that this is the correct behavior. It seems > a bit surprising that UPDATE privilege on a single column is enough to > lock out all SELECT activity from the table. It's actually a bit > surprising that even full-table UPDATE privileges are enough to do > this, but this change would allow people to block access to data they > can neither see nor modify. That seems counterintuitive, if not a > security hole. This comment misses the point. A user can already lock every row of a table, if they choose, by issuing SELECT ... FOR SHARE/UPDATE, if they have update rights on a single column. So the patch does not increase the rights of the user, it merely allows it to happen in a rational way and in a way that makes SELECT and LOCK work the same. -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: