Re: Wrong security context for deferred triggers?
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
pgsql-hackers@lists.postgresql.org
Date: 2024-10-18T05:47:44Z
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
Hi pá 18. 10. 2024 v 7:22 odesílatel Laurenz Albe <laurenz.albe@cybertec.at> napsal: > On Wed, 2024-03-06 at 14:32 +0100, Laurenz Albe wrote: > > On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote: > > > On 11/6/23 14:23, Laurenz Albe wrote: > > > > This behavior looks buggy to me. What do you think? > > > > I cannot imagine that it is a security problem, though. > > > > > > How could code getting executed under the wrong role not be a security > > > issue? Also, does this affect just the role, or are there some other > > > settings that may unexpectedly change (e.g. search_path)? > > > > Here is a patch that fixes this problem by keeping track of the > > current role in the AfterTriggerSharedData. > > Funny enough, this problem has just surfaced on pgsql-general: > > https://postgr.es/m/89e33a53-909c-6a02-bfc6-2578ba974e16@cloud.gatewaynet.com > > I take this as one more vote for this patch... > Yours, > Laurenz Albe > > I am doing a review of this patch. Without deeper checks I don't like using GetUserNameFromId for checking the validity of a role. Maybe it is better to use own read of syscache or wrap SetUserIdAndSecContext to do this check. The comment + /* + * The role could have been dropped since the trigger was queued. + * In that case, give up and error out. + */ doesn't explain well why the role can be dropped and why dependency doesn't protect against it. Regards Pavel