Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] column-level update privs + lock table

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] column-level update privs + lock table
Date: 2010-11-28 23:50:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
(2010/11/27 9:11), Robert Haas wrote:
> 2010/11/25 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> (2010/10/16 4:49), Josh Kupershmidt wrote:
>>> [Moving to -hackers]
>>> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs<simon(at)2ndquadrant(dot)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(at)gmail(dot)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.
In my understanding, UPDATE privilege on a single column also allows
lock out concurrent updating even if this query tries to update rows
Therefore, the current code considers UPDATE privilege on a single
column is enough to lock out the table. Right?

My comment was from a standpoint which wants consistent behavior
between SELECT ... FOR and LOCK command. If we concerned about this
behavior, ExecCheckRTEPerms() might be a place where we also should fix.

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-28 23:57:11
Subject: Re: contrib: auth_delay module
Previous:From: Tom LaneDate: 2010-11-28 23:41:58
Subject: Re: profiling connection overhead

pgsql-general by date

Next:From: Vick KheraDate: 2010-11-29 00:46:43
Subject: Re: ERROR: xlog flush request 17/4D6C2720 is not satisfied
Previous:From: Robert HaasDate: 2010-11-28 21:25:35
Subject: Re: [GENERAL] column-level update privs + lock table

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group