Re: Preventing non-superusers from altering session authorization

I've discovered an issue with this approach. Let's say you have some
session open that is connected as a superuser and you run the following
commands:

- CREATE ROLE r1 LOGIN SUPERUSER;
- CREATE ROLE r2;
- CREATE ROLE r3;

Then you open another session connected with user r1 and run the
following commands:

- SET SESSION AUTHROIZATION r2;
- BEGIN;
- SET SESSION AUTHORIZATION r3;

Then in your original session run:

- ALTER ROLE r1 NOSUPERUSER;

Finally in the r1 session run:

- CREATE TABLE t ();

Postgres will then panic with the following logs:

2023-07-08 16:33:27.787 EDT [157141] ERROR: permission denied for schema
public at character 14
2023-07-08 16:33:27.787 EDT [157141] STATEMENT: CREATE TABLE t ();
2023-07-08 16:33:27.787 EDT [157141] ERROR: permission denied to set
session authorization
2023-07-08 16:33:27.787 EDT [157141] WARNING: AbortTransaction while in
ABORT state
2023-07-08 16:33:27.787 EDT [157141] ERROR: permission denied to set
session authorization
2023-07-08 16:33:27.787 EDT [157141] WARNING: AbortTransaction while in
ABORT state
2023-07-08 16:33:27.787 EDT [157141] ERROR: permission denied to set
session authorization
2023-07-08 16:33:27.787 EDT [157141] WARNING: AbortTransaction while in
ABORT state
2023-07-08 16:33:27.787 EDT [157141] ERROR: permission denied to set
session authorization
2023-07-08 16:33:27.787 EDT [157141] PANIC: ERRORDATA_STACK_SIZE exceeded
2023-07-08 16:33:27.882 EDT [156878] LOG: server process (PID 157141) was
terminated by signal 6: Aborted
2023-07-08 16:33:27.882 EDT [156878] DETAIL: Failed process was running:
CREATE TABLE t ();

I think the issue here is that if a session loses the ability to set
their session authorization in the middle of a transaction, then
rolling back the transaction may fail and cause the server to panic.
That's probably what the deleted comment mean when it said:

> * It's OK because the check does not require catalog access and can't
> * fail during an end-of-transaction GUC reversion

Interestingly, if the r1 session manually types `ROLLBACK` instead of
executing a command that fails, then everything is fine and there's no
panic. I'm not familiar enough with transaction handling to know why
there would be a difference there.

Thanks,
Joe Koshakow