Re: Proposal: Save user's original authenticated identity for logging - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Proposal: Save user's original authenticated identity for logging
Date
Msg-id 20210201220126.GW27507@tamriel.snowman.net
Whole thread Raw
In response to Re: Proposal: Save user's original authenticated identity for logging  (Jacob Champion <pchampion@vmware.com>)
Responses Re: Proposal: Save user's original authenticated identity for logging
List pgsql-hackers
Greetings,

* Jacob Champion (pchampion@vmware.com) wrote:
> 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.

Not sure exactly what you're referring to here but AD already provides
Kerberos with cross-domain trusts (aka forests).  The future is here..?
:)

> > 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?

I don't agree that this really expands its scope- in fact, you'll see
that the GSSAPI and SSL user authentication information is already
allowed under HAS_PGSTAT_PERMISSIONS().

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Proposal: Save user's original authenticated identity for logging
Next
From: Magnus Hagander
Date:
Subject: Re: Proposal: Save user's original authenticated identity for logging