Re: Failed assertion due to procedure created with SECURITY DEFINER option

Hi,

On 2018-06-29 13:56:12 +0200, Peter Eisentraut wrote:
> On 6/29/18 13:07, amul sul wrote:
> > This happens because of in fmgr_security_definer() function we are
> > changing global variable SecurityRestrictionContext and in the
> > StartTransaction() insisting it should be zero, which is the problem.
>
> Hmm, what is the reason for this insistation?

Because it's supposed to be reset by AbortTransaction(), after an error.

/*
* Reset user ID which might have been changed transiently. We need this
* to clean up in case control escaped out of a SECURITY DEFINER function
* or other local change of CurrentUserId; therefore, the prior value of
* SecurityRestrictionContext also needs to be restored.
*
* (Note: it is not necessary to restore session authorization or role
* settings here because those can only be changed via GUC, and GUC will
* take care of rolling them back if need be.)
*/
SetUserIdAndSecContext(s->prevUser, s->prevSecContext);

I think all the state managed by transactions should be reviewed for
interactions with procedures. Can't imagine this being the only issue.

Greetings,

Andres Freund