Re: Row-Trigger implicitly allows users ACL_SELECT

Tom Lane wrote:
> KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
>> * Row-Update/Delete trigger mechanism allows user defined triggers
>> to refer the older tuple updated/deleted.
>> * The ACL_TRIGGER privilege allows normal users to set up triggers
>> on the relation allowed.
>
>> It means someone with ACL_TRIGGER can set up a trigger which write
>> out the given older tuple into somewhere.
>> In logically, it also means users with ACL_TRIGGER and either of
>> ACL_UPDATE or ACL_DELETE are allowed to read the table without
>> ACL_SELECT permission.
>
> Granting TRIGGER privilege already implies an exceedingly high trust
> level, since a trigger can do arbitrary damage to your data. I don't
> find this concern interesting, and your solution wouldn't work anyway
> (AFAICS it would check the permissions of the user doing the UPDATE,
> not those of the user who created the trigger).

I think we have two attitudes/options.
The one considers ACL_TRIGGER just as a privilege to create a trigger,
so we need to check when the backend delivers OLD/NEW into triggers,
as I noted today.
The other considers triggers are high trusted process and ACL_TRIGGER
privilege includes a right to set up such a trusted one, as you noted.

From the point of SE-PostgreSQL, it can accept either of them.
(If we take the later option, it will need db_procedure:{install}
checks (in the future revision), because of it means user defined
triggers installed as a part of system internal stuff.)

The current implementation adopt the former stance, but it may
be better to adopt the later one, in the sense of consistency.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>