Date: Thu, 24 Feb 2022 20:39:48 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Jacob Champion <pchampion@vmware.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers
Message-ID: <YhduhD/SvIX5NnxY@paquier.xyz>
References: <793d990837ae5c06a558d58d62de9378ab525d83.camel@vmware.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="NcKslrfx5RmrqT2v"
Content-Disposition: inline
In-Reply-To: <793d990837ae5c06a558d58d62de9378ab525d83.camel@vmware.com>
Archived-At: <https://www.postgresql.org/message-id/YhduhD/SvIX5NnxY%40paquier.xyz>
Precedence: bulk


--NcKslrfx5RmrqT2v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 24, 2022 at 12:15:40AM +0000, Jacob Champion wrote:
> Stephen pointed out [1] that the authenticated identity that's stored
> in MyProcPort can't be retrieved by extensions or triggers. Attached is
> a patch that provides both a C API and a SQL function for retrieving
> it.
>=20
> GetAuthenticatedIdentityString() is a mouthful but I wanted to
> differentiate it from the existing GetAuthenticatedUserId(); better
> names welcome. It only exists as an accessor because I wasn't sure if
> extensions outside of contrib were encouraged to rely on the internal
> layout of struct Port. (If they can, then that call can go away
> entirely.)

+char *
+GetAuthenticatedIdentityString(void)
+{
+   if (!MyProcPort || !MyProcPort->authn_id)
+       return NULL;
+
+   return pstrdup(MyProcPort->authn_id);

I don't quite see the additional value that this API brings as
MyProcPort is directly accessible, and contrib modules like
postgres_fdw and sslinfo just use that to find the data of the current
backend.  Cannot a module like pgaudit, through the elog hook, do its
work with what we have already in place?

What's the use case for a given session to be able to report back
only its own authn through SQL?

I could still see a use case for that at a more global level with
beentrys, but it looked like there was not much interest the last time
I dropped this idea.
--
Michael

--NcKslrfx5RmrqT2v
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmIXboQACgkQnvQgOdby
QH2Mog//SNYLN3B2jgpynKK33OKoRwtaTglWJMAoIK+tuVsp9Zx8spHxx1ObLOA5
3SN/dbDLOuZb7ZTTAO/K91CJDhERit+36Ux74+YEHaCy/dYhtpFKnvoAsJnG0+6P
u6NHOi1DnXdFO84OGL6e8/YDlWuZGGdH0kWEAg61DIckMjv+77Qvo0grXOYpb5Np
3MeS3D9rclDcXOYiIjMiBMDX8/2x1WyN1nYbUmujSj62R/ZrrimBs4GAjzdy5+e9
JHxOpBSNhEbOFx9Gq+rkHwhw0UOWagvdxWKjz63JkGB/FqJwu2VoxC/tZ3PSiWgd
W99YyIAVWG00TE0zYk+A31hZjlkfN48mzmmC9C3PpGmFkeYvCfbapt0ou2TblBpX
aqfwNsRqljMvuym9/Jn3BepO0mcdTKVmvJvDyERz3ZLRfv8UtMf3fiVEf7bXdJDz
6lWhGOpH/5MPlzOVyuGHdnHEtSbLzIMnn+vSQolG1yvgYapv3u+f43tb+yh1pV3Z
2y4nm0znvkgV26UNme6wXCfRHuaTiG03DMAhtOnBRvfncvnQUAkj01jqZH0P2ydP
+Ca4lLmspkyYRmLo11isZFR6rl2Zh6vie82Sojx8/A5gAa9775cRwjXNCuLTEYpl
qpp+/2OZVDOToWLt/jejulkFab3/KBk/zaCUA2CHgKjz+TAp2VY=
=GnNi
-----END PGP SIGNATURE-----

--NcKslrfx5RmrqT2v--