Re: SYSTEM_USER reserved word implementation
Drouvot, Bertrand <bdrouvot@amazon.com>
From: "Drouvot, Bertrand" <bdrouvot@amazon.com>
To: Joe Conway <mail@joeconway.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <jchampion@timescale.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-23T07:53:39Z
Lists: pgsql-hackers
Hi, On 6/22/22 6:32 PM, Joe Conway wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > > On 6/22/22 12:28, Tom Lane wrote: >> 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. > > Oh, that's an interesting thought -- I like that. > Thanks Joe and Tom for your feedback. I like this idea too and that's also more aligned with what log_connections set to on would report (aka the auth method). Baring any objections, I'll work on that idea. Bertrand
Commits
-
Introduce SYSTEM_USER
- 0823d061b0b7 16.0 landed
-
Add some information about authenticated identity via log_connections
- 9afffcb833d3 14.0 cited