Re: SYSTEM_USER reserved word implementation
| От | David G. Johnston |
|---|---|
| Тема | Re: SYSTEM_USER reserved word implementation |
| Дата | |
| Msg-id | CAKFQuwYmNfMAtMdu1DthodnHYebxfR+Otib_beETB70kt2X1rg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SYSTEM_USER reserved word implementation (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Wed, Jun 22, 2022 at 9:28 AM Tom Lane <tgl@sss.pgh.pa.us> 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.
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.
David J.
В списке pgsql-hackers по дате отправления: