public inbox for [email protected]  

help / color / mirror / Atom feed

From: Joseph Koshakow <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Preventing non-superusers from altering session authorization
Date: Sat, 8 Jul 2023 16:44:06 -0400
Message-ID: <CAAvxfHdJdAb4QVj5nGv5tz8=QuhvxE4Y4B8yRLDdAEz1doU9jA@mail.gmail.com> (raw)
In-Reply-To: <CAAvxfHfzRhoD98UXKE4DZpR5iwznMiehwsuqMzYhfQcnTwQ0Mw@mail.gmail.com>
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>

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

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Preventing non-superusers from altering session authorization
  In-Reply-To: <CAAvxfHdJdAb4QVj5nGv5tz8=QuhvxE4Y4B8yRLDdAEz1doU9jA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox