Re: [GENERAL] column-level update privs + lock table - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [GENERAL] column-level update privs + lock table
Date
Msg-id AANLkTinKWfZtbLyc89n9LvFmT_H=-g8qj_GHVnO+_wSk@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] column-level update privs + lock table  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: [GENERAL] column-level update privs + lock table
List pgsql-hackers
On Tue, Nov 30, 2010 at 7:26 AM, Simon Riggs <simon@2ndquadrant.com> 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 inconsistency be allowed
> to continue?

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
trash the whole table, though, so you are allowing them to deny read
access to data they may not themselves have permission either to read
or to update.

Admittedly, this seems a bit more rickety in light of your point that
they can still lock all the rows... but then that only stops writes,
not reads. I'm less convinced that I'm right about this than I was 3
days ago.  But I'm still not convinced that the above argument is
wrong, either.

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


pgsql-hackers by date:

Previous
From: Daniel Loureiro
Date:
Subject: Re: DELETE with LIMIT (or my first hack)
Next
From: Daniel Loureiro
Date:
Subject: Re: DELETE with LIMIT (or my first hack)