public inbox for [email protected]help / color / mirror / Atom feed
Re: set role command 3+ messages / 3 participants [nested] [flat]
* Re: set role command @ 2025-11-24 19:21 Álvaro Herrera <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Álvaro Herrera @ 2025-11-24 19:21 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Calvin Guo <[email protected]>; [email protected] On 2025-Nov-24, Tom Lane wrote: > =?utf-8?Q?=C3=81lvaro?= Herrera <[email protected]> writes: > > For what it's worth, I think we break the SQL standard's security model > > by providing RESET ROLE and RESET SESSION AUTHORIZATION, neither of > > which the standard has. > > I don't think so. They are just shorthand for issuing a SET to the > original value, so how do they break the model in a way that that > doesn't? No, because the new user doesn't have privs to become the previous one. > > This means that in the standard model you have > > commands to lower your privilege, but once you've lowered them, you > > cannot return (in the same connection) to what you had. > > The reason PG acts as it does is that we interpret "the permissions > required to do SET SESSION AUTHORIZATION" as "did your originally > authenticated ID have permission to do that SET?". I have the impression that that's broken, because for <set session user identifier statement>, the standard says that the current user identifier is set to the new user, which means the previous user identifier is lost. You don't retain rights to become that user again. > In practical terms, the one-way changes that Calvin wants are just not > that attractive. What people have actually asked for, particularly > connection-pooler authors, are a way to switch session authorization > in such a way that you can only go back with some additional secret > sauce, like a one-time password generated at the pooler level. Yeah, I think connection poolers would be better served by a different security model than what the standard offers. The pooler-generated one-time password, or something similar, seems somewhat appropriate given what we offer today. I'm not sure it's the best model either, because it requires that the connection is initially in a superuser-like state (so that it can become any other user). But that's somewhat dangerous, because if an attacker manages to steal the one-time password, they are database superuser and all is lost. It would be more secure to have a mechanism where the connection is initially unauthenticated altogether (which means: it's not a valid SQL session), becomes authenticated at the pooler's will, and returns to unauthenticated state as the pooler decides. Critically, from unauthenticated state you shouldn't be able to become superuser. (Also, last I looked at pgbouncer, it had to do some weird tricks to mimick the authentication on their side without involving the server, so it wanted to keep its own list of user/passwords or something like that. Maybe that's changed in the last few years though.) -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Having your biases confirmed independently is how scientific progress is made, and hence made our great society what it is today" (Mary Gardiner) ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: set role command @ 2025-11-24 19:46 Tom Lane <[email protected]> parent: Álvaro Herrera <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2025-11-24 19:46 UTC (permalink / raw) To: Álvaro Herrera <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Calvin Guo <[email protected]>; [email protected] =?utf-8?Q?=C3=81lvaro?= Herrera <[email protected]> writes: > On 2025-Nov-24, Tom Lane wrote: >> I don't think so. They are just shorthand for issuing a SET to the >> original value, so how do they break the model in a way that that >> doesn't? > No, because the new user doesn't have privs to become the previous one. Don't think you can make that argument from the standard, since it explicitly disclaims saying what privs are required. > It would be more > secure to have a mechanism where the connection is initially > unauthenticated altogether (which means: it's not a valid SQL session), > becomes authenticated at the pooler's will, and returns to > unauthenticated state as the pooler decides. Critically, from > unauthenticated state you shouldn't be able to become superuser. I don't like the idea that a pooler or pretend-to-be pooler can eat up a backend session without having authenticated at all. Also, exactly what does "becomes authenticated at the pooler's will" mean? There had better be some actual authentication happening somewhere. If we tried doing that, I'd prefer that the "rest state" be validly authenticated, but it could be as a low-privilege user that can't do much of anything. However, then we'd need to have an actual authentication exchange to raise privilege to whatever you wanted to do useful work as, and that would have to be a protocol-level thing not a SQL command. I also wonder how much poolers would really want to use that, because it'd partially defeat the goal of quickly switching to different users. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: set role command @ 2025-11-24 20:25 Ron Johnson <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Ron Johnson @ 2025-11-24 20:25 UTC (permalink / raw) To: pgsql-generallists.postgresql.org <[email protected]> On Mon, Nov 24, 2025 at 2:46 PM Tom Lane <[email protected]> wrote: > =?utf-8?Q?=C3=81lvaro?= Herrera <[email protected]> writes: > > On 2025-Nov-24, Tom Lane wrote: > >> I don't think so. They are just shorthand for issuing a SET to the > >> original value, so how do they break the model in a way that that > >> doesn't? > > > No, because the new user doesn't have privs to become the previous one. > > Don't think you can make that argument from the standard, since > it explicitly disclaims saying what privs are required. > > > It would be more > > secure to have a mechanism where the connection is initially > > unauthenticated altogether (which means: it's not a valid SQL session), > > becomes authenticated at the pooler's will, and returns to > > unauthenticated state as the pooler decides. Critically, from > > unauthenticated state you shouldn't be able to become superuser. > > I don't like the idea that a pooler or pretend-to-be pooler > can eat up a backend session without having authenticated at all. > Also, exactly what does "becomes authenticated at the pooler's will" > mean? There had better be some actual authentication happening > somewhere. > A restriction that it can only happen when TLS authentication is used, and the pooler is using its service account? -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster! ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-11-24 20:25 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-24 19:21 Re: set role command Álvaro Herrera <[email protected]> 2025-11-24 19:46 ` Tom Lane <[email protected]> 2025-11-24 20:25 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox