Re: [PATCH] Expose port->authn_id to extensions and triggers - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id Yhm9BUjrCItExUJu@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Andres Freund <andres@anarazel.de>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> Looks to me like authn_id isn't synchronized to parallel workers right now. So
> the function will return the wrong thing when executed as part of a parallel
> query.

FWIW, I am not completely sure what's the use case for being able to
see the authn of the current session through a trigger.  We expose
that when log_connections is enabled, for audit purposes.  I can also
get behind something more central so as one can get a full picture of
the authn used by a bunch of session, particularly with complex HBA
policies, but this looks rather limited to me in usability.  Perhaps
that's not enough to stand as an objection, though, and the patch is
dead simple.

> I don't think we should add further functions not prefixed with pg_.

Yep.

> Perhaps a few tests for less trivial authn_ids could be worthwhile?
> E.g. certificate DNs.

Yes, src/test/ssl would handle that just fine.  Now, this stuff
already looks after authn results with log_connections=on, so that
feels like a duplicate.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Frontend error logging style
Next
From: Michael Paquier
Date:
Subject: Re: Commitfest manager for 2022-03