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

On Tue, Nov 30, 2010 at 1:48 PM, Tom Lane wrote: > On the whole I agree with Robert --- let's just adjust the > documentation, and not enlarge privileges in a way we might regret > later. Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

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

(2010/11/30 21:26), Simon Riggs wrote: > On Mon, 2010-11-29 at 21:37 -0500, Josh Kupershmidt wrote: > >> I still see little reason to make LOCK TABLE permissions different for >> column-level vs. table-level UPDATE privileges > > Agreed. > > This is the crux of the debate. Why should this incons

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

Robert Haas writes: > Well, a user with full-table UPDATE privileges can trash the whole > thing, so, from a security perspective, letting them lock is only > allowing them to deny access to data they could have just as easily > trashed. A user with only single-column UPDATE privileges cannot > t

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

On Tue, Nov 30, 2010 at 7:26 AM, Simon Riggs wrote: > On Mon, 2010-11-29 at 21:37 -0500, Josh Kupershmidt wrote: > >> I still see little reason to make LOCK TABLE permissions different for >> column-level vs. table-level UPDATE privileges > > Agreed. > > This is the crux of the debate. Why should

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

On Mon, 2010-11-29 at 21:37 -0500, Josh Kupershmidt wrote: > I still see little reason to make LOCK TABLE permissions different for > column-level vs. table-level UPDATE privileges Agreed. This is the crux of the debate. Why should this inconsistency be allowed to continue? Are there covert ch

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

On Tue, Nov 30, 2010 at 9:07 AM, Josh Kupershmidt wrote: > On Mon, Nov 29, 2010 at 10:06 PM, Robert Haas wrote: >> On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt wrote: >>> I actually hadn't thought of that, for some reason. >>> >>> We used to similarly recommend that people handle TRUNCATE p

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

On Mon, Nov 29, 2010 at 10:06 PM, Robert Haas wrote: > On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt wrote: >> I actually hadn't thought of that, for some reason. >> >> We used to similarly recommend that people handle TRUNCATE privileges >> with a security definer function. That doesn't mean

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

On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt wrote: >> It seems to me that if we're really worried about which locks users >> are allowed to take (and so far all of the worrying seems to lack a >> solid basis in any sort of usability argument) we'd need to invent >> some special-purpose permi

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

On Mon, Nov 29, 2010 at 10:50 AM, Robert Haas wrote: > A user with single-column UPDATE privileges could obtain a ROW > EXCLUSIVE lock by issuing an UPDATE statement, but currently cannot > obtain the same lock using LOCK TABLE.  It would be reasonable and > consistent to allow such a user to take

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

2010/11/28 KaiGai Kohei : >>> 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 shou

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

(2010/11/29 10:43), Robert Haas wrote: > 2010/11/28 KaiGai Kohei: >>> 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 >>> surprisin

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

2010/11/28 KaiGai Kohei : >> 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

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

(2010/11/27 9:11), Robert Haas wrote: > 2010/11/25 KaiGai Kohei: >> (2010/10/16 4:49), Josh Kupershmidt wrote: >>> [Moving to -hackers] >>> >>> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs >>> wrote: On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: > On Thu, Oct 7, 2010 at 7:

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

On Sun, Nov 28, 2010 at 11:35 AM, Simon Riggs wrote: > On Fri, 2010-11-26 at 19:11 -0500, Robert Haas wrote: >> 2010/11/25 KaiGai Kohei : >> > (2010/10/16 4:49), Josh Kupershmidt wrote: >> >> [Moving to -hackers] >> >> >> >> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs   >> >> wrote: >> >>> On Mon

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

On Fri, 2010-11-26 at 19:11 -0500, Robert Haas wrote: > 2010/11/25 KaiGai Kohei : > > (2010/10/16 4:49), Josh Kupershmidt wrote: > >> [Moving to -hackers] > >> > >> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs wrote: > >>> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: > On Thu, O

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

On Fri, Nov 26, 2010 at 7:11 PM, Robert Haas wrote: > 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-tabl

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

2010/11/25 KaiGai Kohei : > (2010/10/16 4:49), Josh Kupershmidt wrote: >> [Moving to -hackers] >> >> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs  wrote: >>> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt   wrote: > I n

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

(2010/10/16 4:49), Josh Kupershmidt wrote: > [Moving to -hackers] > > On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs wrote: >> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: >>> On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt wrote: >>> I noticed that granting a user column-level

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

On Mon, Oct 18, 2010 at 10:27 AM, Robert Haas wrote: > Please add this to > https://commitfest.postgresql.org/action/commitfest_view/open > > I want to look at this at some point, but we still have over a dozen > patches from the current CF to deal with. Added at

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

On Fri, Oct 15, 2010 at 3:49 PM, Josh Kupershmidt wrote: > [Moving to -hackers] > > On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs wrote: >> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: >>> On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt wrote: >>> >>> > I noticed that granting a us

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

[Moving to -hackers] On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs wrote: > On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: >> On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt wrote: >> >> > I noticed that granting a user column-level update privileges doesn't >> > allow that user to i