From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Russell Foster <russell(dot)foster(dot)coding(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Patch] Using Windows groups for SSPI authentication |
Date: | 2020-10-13 19:32:14 |
Message-ID: | 3485685.1602617534@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Russell Foster <russell(dot)foster(dot)coding(at)gmail(dot)com> writes:
> Going to take a guess at what you mean by:
>> I do object to using syntax that makes random assumptions about what a
>> user name can or can't be.
> Are you referring to the "+" syntax in the ident file? I chose that because
> somewhere else (hba?) using the same syntax for groups. The quotes are just
> there to make the group name case sensitive.
If this were a Postgres group name, I'd say yeah we already broke
the case of spelling group names with a leading "+". (Which I'm
not very happy about either, but the precedent is there.)
However, this isn't. Unless I'm totally confused, the field you're
talking about is normally an external, operating-system-defined name.
I do not think it's wise to make any assumptions about what those
can be.
By the same token, the idea of using a "pg_" prefix as discussed
in the other thread will not work here :-(.
After a few minutes' thought, the best I can can come up with is
to extend the syntax of identmap files with an "options" field,
so that your example becomes something like
# MAPNAME SYSTEM-USERNAME PG-USERNAME OPTIONS
"Users" "User group" postgres windows-group
I'm envisioning OPTIONS as allowing a comma- or space-separated
list of keywords, which would give room to grow for other special
features we might want later.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2020-10-13 20:20:31 | Re: avoid bitmapOR-ing indexes with scan condition inconsistent with partition constraint |
Previous Message | Cary Huang | 2020-10-13 19:23:30 | Re: Improve pg_dump dumping publication tables |