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

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.

> BTW, how about backporting this patch?
> It seems to me a bug fix, although it contains user visible changes.

I don't think it's a bug fix; and even if could be so construed, I
don't think it's important enough to back-patch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company