From: Jacob Champion <pchampion@vmware.com>
To: magnus@hagander.net <magnus@hagander.net>
To: sfrost@snowman.net <sfrost@snowman.net>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Proposal: Save user's original authenticated identity for logging
Date: Mon, 1 Feb 2021 21:50:54 +0000
Message-ID: <57b741e9388f3bd97486615ea1f968c8eee9f055.camel@vmware.com> (raw)
In-Reply-To: <20210201164905.GI27507@tamriel.snowman.net>
References: <c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com>
<20210129220101.GE27507@tamriel.snowman.net>
<e5bcc7f6bf9a3bd7751f97e2c34a5b877d3cbe4c.camel@vmware.com>
<CABUevExLkKQFK3un7veD=yoztJO+gnAuAF4RTbdHLF+-pkAfYA@mail.gmail.com>
<20210201164905.GI27507@tamriel.snowman.net>
On Mon, 2021-02-01 at 11:49 -0500, Stephen Frost wrote:
> * Magnus Hagander (magnus@hagander.net) wrote:
> > But yes, I think the enforced cleartext password proxying is at the
> > core of the problem. LDAP also encourages the idea of centralized
> > password-reuse, which is not exactly a great thing for security.
>
> Right- passing around a user's password in the clear (or even through an
> encrypted tunnel) has been strongly discouraged for a very long time,
> for very good reason. LDAP does double-down on that by being a
> centralized password, meaning that someone's entire identity (for all
> the services that share that LDAP system, at least) are compromised if
> any one system in the environment is.
Sure. I don't disagree with anything you've said in that paragraph, but
as someone who's implementing solutions for other people who are
actually deploying, I don't have a lot of control over whether a
customer's IT department wants to use LDAP or not. And I'm not holding
my breath for LDAP servers to start implementing federated identity,
though that would be nice.
> Also, if we do add
> it, I would think we'd have it under the same check as the other
> sensitive pg_stat_activity fields and not be superuser-only.
Just the standard HAS_PGSTAT_PERMISSIONS(), then?
To double-check -- since giving this ability to the pg_read_all_stats
role would expand its scope -- could that be dangerous for anyone?
--Jacob
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: pgsql-hackers@postgresql.org
Cc: pchampion@vmware.com, magnus@hagander.net, sfrost@snowman.net
Subject: Re: Proposal: Save user's original authenticated identity for logging
In-Reply-To: <57b741e9388f3bd97486615ea1f968c8eee9f055.camel@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox