Message-ID: <49E974AD.3020602@enterprisedb.com>
Date: Sat, 18 Apr 2009 09:35:25 +0300
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: KaiGai Kohei <kaigai@kaigai.gr.jp>
CC: Tom Lane <tgl@sss.pgh.pa.us>, KaiGai Kohei <kaigai@ak.jp.nec.com>,
	pgsql-hackers@postgresql.org
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
References: <49E809F6.8070008@ak.jp.nec.com>
	<49E8133A.7090601@enterprisedb.com>
	<49E81EA1.2060202@ak.jp.nec.com> <20069.1239977115@sss.pgh.pa.us>
	<49E91AE4.9020404@kaigai.gr.jp>
In-Reply-To: <49E91AE4.9020404@kaigai.gr.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

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