Re: Proposal: Role Sandboxing for Secure Impersonation

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Wolfgang Walther <walther(at)technowledgy(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Eric Hanson <eric(at)aquameta(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Role Sandboxing for Secure Impersonation
Date: 2024-12-05 09:49:01
Message-ID: CAGECzQTCLyv064H_BSqRyQb_GFf3mbAZgu=RZhLkPP413-A02w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 5 Dec 2024 at 09:47, Wolfgang Walther <walther(at)technowledgy(dot)de> wrote:
> Right, I should have clarified: My proposal wasn't mean to be taken
> literally as an SQL command. Passwords should not be sent as plain text,
> no question. This needs to happen on the protocol level.

Thanks for clarifying.

> I don't want to give any privileges to the connection pooler /
> application and I don't want to outsource authentication.

I understand the security consideration and I think it's valid. But
I'd like to call out for completeness that such an approach (when
using scram) would require two roundtrips, instead of just one like
for option e). So for an admin this is a tradeoff (security vs perf),
not simply better.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-12-05 09:49:23 Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY
Previous Message Jakub Wartak 2024-12-05 09:43:41 doc: Mention clock synchronization recommendation for hot_standby_feedback