Greetings, * Jacob Champion (pchamp...@vmware.com) wrote: > On Mon, 2021-02-01 at 11:49 -0500, Stephen Frost wrote: > > * Magnus Hagander (mag...@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
signature.asc
Description: PGP signature