2010/11/25 KaiGai Kohei <kai...@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<si...@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<schmi...@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. > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
