Re: Wrong security context for deferred triggers?
Joseph Koshakow <koshy44@gmail.com>
From: Joseph Koshakow <koshy44@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
pgsql-hackers@lists.postgresql.org, isaac.morland@gmail.com
Date: 2024-07-08T02:14:57Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: improve description of which role runs a trigger.
- c37be39a74b2 18.0 landed
-
Change role names used in trigger test.
- 4b05ebf0957b 18.0 landed
-
Ensure that AFTER triggers run as the instigating user.
- 01463e1cccd3 18.0 landed
-
Reverse the search order in afterTriggerAddEvent().
- 7921927bbb9d 18.0 landed
On Mon, Jul 1, 2024 at 11:45 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote: > I asked them for a statement, and they were nice enough to write up > https://postgr.es/m/e89e8dd9-7143-4db8-ac19-b2951cb0c0da%40gmail.com > They have a workaround, so the patch is not absolutely necessary for them. It sounds like the issue is that there is there is a constraint trigger to check a table constraint that must be executed at commit time, and we'd like to guarantee that if the triggering action was successful, then the constraint check is also successful. This is an even bigger issue for transactions that have multiple of these constraint checks where there may be no single role that has the privileges required to execute all checks. Your patch would fix the issue in a majority of cases, but not all. Since INSERT, UPDATE, DELETE privileges don't necessarily imply SELECT privileges, the role that modifies a table doesn't necessarily have the privileges required to check the constraints. It sounds like creating the constraint check triggers as a security definer function, with a role that has SELECT privileges, is the more complete solution rather than a workaround. Given the above and the fact that the patch is a breaking change, my vote would still be to keep the current behavior and update the documentation. Though I'd be happy to be overruled by someone with more knowledge of triggers. Thanks, Joe Koshakow