(2010/11/29 10:43), Robert Haas wrote: > 2010/11/28 KaiGai Kohei<kai...@ak.jp.nec.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. > I thought the author concerned about inconsistency between them. (Perhaps, I might misunderstood his motivation?)
What was the purpose that this patch tries to solve? In the first message of this topic, he concerned as follows: > 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. Do we need to answer: "Yes, it is a specification, so you need to grant table level privileges, instead"? Thanks -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
