Re: Wrong security context for deferred triggers?
| От | Pavel Stehule |
|---|---|
| Тема | Re: Wrong security context for deferred triggers? |
| Дата | |
| Msg-id | CAFj8pRDcE3+9EM+PSSEW1bHA-EWMAYgVog41q0c47N=Pnq_qiQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Wrong security context for deferred triggers? (Laurenz Albe <laurenz.albe@cybertec.at>) |
| Ответы |
Re: Wrong security context for deferred triggers?
|
| Список | pgsql-hackers |
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.
+ */
+ * 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
В списке pgsql-hackers по дате отправления: