Re: Column-Level Privileges

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org, Markus Wanner <markus(at)bluegap(dot)ch>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: Column-Level Privileges
Date: 2009-01-20 18:52:50
Message-ID: 9375.1232477570@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

... btw, what is the reasoning behind the special cases for SELECT FOR
UPDATE in execMain.c?

/* Check if this is SELECT-FOR-UPDATE and handle
* accordingly. */
if(remainingPerms & ACL_UPDATE &&
pg_attribute_aclcheck_all(relOid, userid,
ACL_UPDATE, ACLMASK_ALL) != ACLCHECK_OK)
aclcheck_error(ACLCHECK_NO_PRIV, ACL_KIND_CLASS,
get_rel_name(relOid));

If there actually is a need to treat SELECT FOR UPDATE specially, then
this code is quite wrong because it will also fire on a plain UPDATE
(assuming the UPDATE reads any existing column values, which it usually
would). Offhand though I don't see why we can't just use code that is
symmetric with the SELECT case: if requiredPerms includes UPDATE but
there are no columns called out for UPDATE, then allow it if we have
UPDATE on any column.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2009-01-20 19:01:55 Re: Column-Level Privileges
Previous Message Simon Riggs 2009-01-20 18:09:18 Re: Visibility map and freezing