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

From Jacob Champion
Subject Re: Proposal: Save user's original authenticated identity for logging
Date
Msg-id c65fd6360d9a174dcf98b1e2e7d02ca654e0ca85.camel@vmware.com
Whole thread Raw
In response to Re: Proposal: Save user's original authenticated identity for logging  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: Save user's original authenticated identity for logging  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2021-01-29 at 17:30 -0500, Tom Lane wrote:
> What happens if ALTER USER RENAME is done while the session is still
> alive?

IMO the authenticated identity should be write-once. Especially since
one of my goals is to have greater auditability into events as they've
actually happened. So ALTER USER RENAME should have no effect.

This also doesn't really affect third-party auth methods. If I'm bound
as pchampion@EXAMPLE.COM and a superuser changes my username to tlane,
you _definitely_ don't want to see my authenticated identity change to 
tlane@EXAMPLE.COM. That's not who I am.

So the potential confusion would come into play with first-party authn.
From an audit perspective, I think it's worth it. I did authenticate as
pchampion, not tlane.

> More generally, exposing this in log_line_prefix seems like an awfully
> narrow-minded view of what people will want it for.  I'd personally
> think pg_stat_activity a better place to look, for example.
> [...]
> Yeah, this seems like about the most expensive way that we could possibly
> choose to make the info available.

I'm happy as long as it's _somewhere_. :D It's relatively easy to
expose a single location through multiple avenues, but currently there
is no single location.

--Jacob

pgsql-hackers by date:

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