Joe Conway <mail@joeconway.com> writes: > On 6/22/22 11:52, Tom Lane wrote: >> I think a case could be made for ONLY returning non-null when authn_id >> represents some externally-verified identifier (OS user ID gotten via >> peer identification, Kerberos principal, etc).
> But -1 on that.
> I think any time we have a non-null authn_id we should expose it. Are > there examples of cases when we have authn_id but for some reason don't > trust the value of it?
I'm more concerned about whether we have a consistent story about what SYSTEM_USER means (another way of saying "what type is it"). If it's just the same as SESSION_USER it doesn't seem like we've added much.
Maybe, instead of just being the raw user identifier, it should be something like "auth_method:user_identifier" so that one can tell what the identifier actually is and how it was verified.
I was thinking this was trying to make the following possible:
psql -U postgres
# set session authorization other_superuser;
# set role other_role;
# select system_user, session_user, current_user;
postgres | other_superuser | other_role
Though admittedly using "system" for that seems somehow wrong. connection_user would make more sense. Then the system_user would be, if applicable, an external identifier that got matched with the assigned connection_user. I can definitely see having the external identifier be a structured value.
