| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: wiki.postgres Tighten trigger permission checks already resolved |
| Date: | 2023-04-25 03:06:28 |
| Message-ID: | 603516.1682391988@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
jian he <jian(dot)universality(at)gmail(dot)com> writes:
> The following Todo item seems already resolved in pg15.
> https://wiki.postgresql.org/wiki/Todo#Triggers
>> Tighten trigger permission checks
>> - Security leak with trigger functions?
>> <http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php>
> But it seems to not appear in the pg15 release notes. (I searched for the
> keywords "trigger" and "function").
The case shown at the head of that thread was fixed more than a decade
ago, cf commit 891e6e7bf (CVE-2012-0866). However, the followup questions
discussed in the thread are still live: should there be a run-time not
only trigger-creation-time privilege check, and if so what should it
check exactly? And is a separate TRIGGER privilege even reasonable,
rather than just saying you must be table owner to create a trigger?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeffrey Walton | 2023-04-25 03:22:11 | Re: murmur3 hash binary data migration from Oracle to PostgreSQL |
| Previous Message | Erik Wienhold | 2023-04-25 02:15:35 | Re: murmur3 hash binary data migration from Oracle to PostgreSQL |