Re: Proposal: Role Sandboxing for Secure Impersonation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal: Role Sandboxing for Secure Impersonation
Date
Msg-id CA+TgmoZptD9O-qRtxgoVqOm87f0itazdneq89J=khK-UdngnuQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Role Sandboxing for Secure Impersonation  (Joe Conway <mail@joeconway.com>)
Responses Re: Proposal: Role Sandboxing for Secure Impersonation
List pgsql-hackers
On Wed, Dec 4, 2024 at 2:02 PM Joe Conway <mail@joeconway.com> wrote:
> However on that thread[1] Jelte and Robert expressed a preference to
> accomplishing the goal via protocol changes. That is not my preference,
> but it would be worth hearing from them how firm they are in their
> resolve -- i.e. if we went down the path of adding grammar and support
> along the lines discussed here will they seek to block it from being
> committed? And similarly for others that have not spoken up at all.

I do think the protocol change is better. I think we'd likely have it
already if Jelte hadn't switched employers, but oh well.

I wouldn't oppose a command that does an absolutely irrevocable SET
ROLE -- i.e. once you execute it, it is as if you logged in as the
target role originally, and the only way to get your privileges back
is a new connection.

I am extremely skeptical of something like SET ROLE WITH <password>.
To me, that just seems under-engineered -- why would anyone prefer
that over a protocol-level facility, which seems so much more secure
and less hacky? If it turns out anyone can guess or steal the secret,
then that's a CVE, which is no fun at all. And there's lots of vectors
for trying to steal that secret -- logfiles, pg_stat_activity,
probably others.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Cannot find a working 64-bit integer type on Illumos
Next
From: Tom Lane
Date:
Subject: Re: Cannot find a working 64-bit integer type on Illumos