Re: Proposal: Save user's original authenticated identity for logging

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