Re: [PATCH] Expose port->authn_id to extensions and triggers

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers
Date: 2022-02-26 05:39:17
Message-ID: Yhm9BUjrCItExUJu@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-02-26 05:42:33 Re: Commitfest manager for 2022-03
Previous Message Michael Paquier 2022-02-26 05:21:01 Re: Frontend error logging style