From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | column-level update privs + lock table |
Date: | 2010-10-07 23:43:20 |
Message-ID: | AANLkTimVe-V4rbnJa-QTAnz-703vCUEH9tMd9g6VbXAj@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Hi all,
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.
The documentation page for LOCK TABLE claims: "All other forms of LOCK
require at least one of UPDATE, DELETE, or TRUNCATE privileges.", and
I don't see a good reason why column-level privileges shouldn't be
enough to let the user use LOCK TABLE. Is this just an oversight?
Example below:
CREATE ROLE unpriv WITH LOGIN;
CREATE TABLE bar (id int primary key, comment text);
GRANT SELECT ON bar TO unpriv;
GRANT SELECT, UPDATE (comment) ON TABLE bar TO unpriv;
and then, as user "unpriv":
BEGIN;
LOCK TABLE bar IN ROW SHARE MODE;
COMMIT;
Josh
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2010-10-08 02:17:38 | Re: postgreSQL for Windows 7 |
Previous Message | Raymond O'Donnell | 2010-10-07 22:22:35 | Re: [Slony1-general] [ANNOUNCE] Slony-I 2.0.5 Released |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-10-07 23:44:27 | Re: Issues with Quorum Commit |
Previous Message | Greg Smith | 2010-10-07 23:29:10 | Re: O_DSYNC broken on MacOS X? |