Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Date
Msg-id 49E974AD.3020602@enterprisedb.com
Whole thread Raw
In response to Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
List pgsql-hackers
KaiGai Kohei wrote:
> We have an another approach that defines ACL_SELECT_FOR_SHARE as
> an alias of ACL_SELECT, and applies it on SELECT FOR SHARE statement.
> (Needless to say, the targets are already listed, so it might not necessary
> to put a ACL_SELECT_FOR_SHARE bit explicitly.)

That's even more useless, since you need ACL_SELECT for SELECT FOR SHARE
anyway.

> In the LOCK statement, it checks ACL_SELECT privilege for shared locks and
> discriminate between shared and exclusive locks. It seems to me quite natural.

It checks ACL_SELECT for *Access*ShareLock. SELECT FOR SHARE acquires a
RowShareLock. So the equivalent of "SELECT * FROM foo FOR SHARE" using
LOCK is "LOCK TABLE foo RowShareLock", which checks
ACL_UPDATE|ACL_DELETE|ACL_TRUNCATE.

IMHO the only sane change would be to introduce a new
ACL_SELECT_FOR_SHARE permission for SELECT FOR SHARE. That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
into other tables that have a foreign key reference to it, without
having to grant UPDATE permission.

Does the SQL spec have anything to say about this, BTW?

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCH] SE-PostgreSQL for v8.5 development (r1819)
Next
From: Pavel Golub
Date:
Subject: [PATCH] Borland C Compiler compatibility issues