Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> 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.
>>
>> ... but this argument for it is utter nonsense. FKs are not a
>> permissions problem, because the triggers run as the table's owner.
>> The only permission you need is REFERENCES:
>
> Then I think we should leave it as it is. I don't see any plausible use
> case for a separate SELECT FOR SHARE or UPDATE permission.
My concern is not on the vanilla PostgreSQL's access controls.
In the discussion for v8.4 development cycle, I got a suggestion that
the query-tree-walker routine is a duplication of the code so we should
utilize the information collected by the core analyzer. I agreed this
design changes and it enabled to simplify the implementation.
However, ACL_UPDATE and ACL_SELECT_FOR_UPDATE internally shares same bit
so SE-PostgreSQL cannot discriminate between UPDATE and SELECT FOR UPDATE
or SHARE. It has been a headach for me.
Last night, I got an another idea without any changes ACL_xxx definitions.
If the given rte->requiredPerms has ACL_UPDATE (or ACL_SELECT_FOR_UPDATE),
we might be able to discriminate them using rte->modifiedCols, because
UPDATE statement set a bit on rte->modifiedCols at least.
if (rte->requiredPerms & ACL_UPDATE) { if (bms_is_empty(rte->modifiedCols)) // consider it as SELECT
FORUPDATE/SHARE else // consider it as UPDATE }
If we don't have a (internally) separate bit on ACL_SELECT_FOR_UPDATE,
it can be a solution for SE-PostgreSQL.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
