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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(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-27 00:11:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-27 00:16:20
Subject: Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running
Previous:From: Robert HaasDate: 2010-11-27 00:02:27
Subject: Re: Assertion failure on hot standby

pgsql-general by date

Next:From: Zhipan WangDate: 2010-11-27 08:52:56
Subject: Question about OID and TCID
Previous:From: Craig RingerDate: 2010-11-26 23:49:25
Subject: Re: Terms advice.

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