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-29 01:43:34
Message-ID: AANLkTi=0_m2x0FXLGOMO-SVYw-mBLwMzTXyUfgpt-bw5@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
2010/11/28 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> 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
> partially.
> Therefore, the current code considers UPDATE privilege on a single
> column is enough to lock out the table. Right?

Against concurrent updates and deletes, yes.  Against inserts that
don't involve potential unique-index conflicts, and against selects,
no.

> My comment was from a standpoint which wants consistent behavior
> between SELECT ... FOR and LOCK command.

Again, nothing about this makes those consistent.

> If we concerned about this
> behavior, ExecCheckRTEPerms() might be a place where we also should fix.

I don't understand what you're getting at here.

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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-29 01:44:38
Subject: Re: Feature request: INSERT .... ON DUPLICATE UPDATE ....
Previous:From: Robert HaasDate: 2010-11-29 01:40:08
Subject: Re: Patch to add a primary key using an existing index

pgsql-general by date

Next:From: Scott MarloweDate: 2010-11-29 01:54:14
Subject: Re: ERROR: xlog flush request 17/4D6C2720 is not satisfied
Previous:From: Vick KheraDate: 2010-11-29 00:46:43
Subject: Re: ERROR: xlog flush request 17/4D6C2720 is not satisfied

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