Re: [PATCH] Expose port->authn_id to extensions and triggers
Jacob Champion <pchampion@vmware.com>
From: Jacob Champion <pchampion@vmware.com>
To: "andres@anarazel.de" <andres@anarazel.de>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Cc: "rjuju123@gmail.com" <rjuju123@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "michael@paquier.xyz" <michael@paquier.xyz>, "sfrost@snowman.net" <sfrost@snowman.net>
Date: 2022-03-29T23:38:29Z
Lists: pgsql-hackers
Attachments
- since-v7.diff.txt (text/plain)
- v8-0001-Add-API-to-retrieve-authn_id-from-SQL.patch (text/x-patch) patch v8-0001
- v8-0002-Allow-parallel-workers-to-use-pg_session_authn_id.patch (text/x-patch) patch v8-0002
On Sat, 2022-03-26 at 11:36 -0700, Andres Freund wrote: > > I also note that exposing it as a GUC means we have zero control over > > who/what can read it. Maybe that's not a problem, but it needs to be > > thought about before we go down that path. > > Yes, I think that's a fair concern. I like that there's no builtin way, today, for a superuser to modify the internal value; it strengthens the use as an auditing tool. Moving this to a PGC_SU_BACKEND GUC seems to weaken that. And it looks like PGC_INTERNAL is skipped during the serialization, so if we chose that option, we'd need to write new code anyway? We'd also need to guess whether the GUC system's serialization of NULL as an empty string is likely to cause problems for any future auth methods. My guess is "no", to be honest, but I do like maintaining the distinction -- it feels safer. v8 rebases over the recent SSL changes to get the cfbot green again. Thanks, --Jacob
Commits
-
Remove initialization of MyClientConnectionInfo at backend startup
- 701ac2cb1fa2 16.0 landed
-
Allow parallel workers to retrieve some data from Port
- d951052a9e02 16.0 landed