Date: Sat, 8 Jul 2023 15:09:04 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Joseph Koshakow <koshy44@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Preventing non-superusers from altering session authorization
Message-ID: <20230708220904.GB4044380@nathanxps13>
References: <CAAvxfHc-HHzONQ2oXdvhFF9ayRnidPwK+fVBhRzaBWYYLVQL-g@mail.gmail.com>
 <20230622034818.GA1077640@nathanxps13>
 <CAAvxfHdj5H88W99anUoFf4OaH+Oozs=e7kF1mhsegxpWOsvQFQ@mail.gmail.com>
 <20230623175416.GA1268820@nathanxps13>
 <CAAvxfHfSbyHp62bqtovsEKu4M3oCQ-mehfq0OJ7Fk3OqkLwXtw@mail.gmail.com>
 <CAAvxfHfzRhoD98UXKE4DZpR5iwznMiehwsuqMzYhfQcnTwQ0Mw@mail.gmail.com>
 <CAAvxfHdJdAb4QVj5nGv5tz8=QuhvxE4Y4B8yRLDdAEz1doU9jA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAvxfHdJdAb4QVj5nGv5tz8=QuhvxE4Y4B8yRLDdAEz1doU9jA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230708220904.GB4044380%40nathanxps13>
Precedence: bulk

On Sat, Jul 08, 2023 at 04:44:06PM -0400, Joseph Koshakow wrote:
> 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

Yeah.  IIUC the ERROR longjmps to a block that calls AbortTransaction(),
which ERRORs again when resetting the session authorization, which causes
us to call AbortTransaction() again, etc., etc.

> 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.

I haven't had a chance to dig into this one yet, but that is indeed
interesting.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com