On Mon, 2021-03-08 at 22:16 +0000, Jacob Champion wrote: > On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote: > > With this we store the same value as the authn and as > > port->gss->princ, and AFAICT it's only used once. Seems we could just > > use the new field for the gssapi usage as well? Especially since that > > usage only seems to be there in order to do the gssapi specific > > logging of, well, the same thing. > > > > [...] > > Seems reasonable; I'll consolidate them.
A slight hitch in the plan, for the GSS side... port->gss->princ is exposed by pg_stat_gssapi. I can switch this to use port->authn_id easily enough. But it seems like the existence of a user principal for the connection is independent of whether or not you're using that principal as your identity. For example, you might connect via a "hostgssenc ... trust" line in the HBA. (This would be analogous to presenting a user certificate over TLS but not using it to authenticate to the database.) I'd argue that the principal should be available through the stats view in this case as well, just like you can see a client DN in pg_stat_ssl even if you're using trust auth. The server doesn't currently support that -- gss->princ is only populated in the gss auth case, as far as I can tell -- but if I remove gss->princ entirely, then it'll be that much more work for someone who wants to expose that info later. I think it should remain independent. Thoughts? --Jacob
