Greetings,
* Russell Foster (russell.foster.coding@gmail.com) wrote:
> Right after I sent that I realized that sspi-group was a bad idea, not sure
> if that's even a thing. Tried to cancel as it was still in moderation, but
> it made it through anyways! You are right, it is very windows specific. I
> can make it windows-group as you said, and resubmit.
Please don't top-post on these lists..
> On Tue, Oct 13, 2020 at 4:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > Russell Foster <russell.foster.coding@gmail.com> writes:
> > > I understand your concerns overall, and the solution you propose seems
> > > reasonable. But are we just using "windows-group" because the code is not
> > > there today to check for a user in another OS group?
> >
> > It's not clear to me whether Windows groups have exact equivalents in
> > other OSes. If we think the concept is generic, I'd be okay with
> > spelling the keyword system-group or the like. The patch you
> > proposed looked pretty Windows-specific though. Somebody with more
> > SSPI knowledge than me would have to opine on whether "sspi-group"
> > is a reasonable name.
While not exactly the same, of course, they are more-or-less equivilant
to Unix groups (it's even possible using NSS to get Unix groups to be
backed by Windows groups) and so calling it 'system-group' does seem
like it'd make sense, rather than calling it "Windows groups" or
similar.
One unfortunate thing regarding this is that, unless things have
changed, this won't end up working with GSS (unless we add the unix
group support and that's then backed by AD as I described above) since
the ability to check group membership using SSPI is an extension to the
Kerberos protocol, which never included group membership information in
it, and therefore while this would work for Windows clients connecting
to Windows servers, it won't work for Windows clients connecting to Unix
servers with GSSAPI authentication.
The direction I had been thinking of addressing that was to add an
option to pg_hba.conf's 'gss' auth method which would allow reaching out
to check group membership against an AD server. In a similar vein, we
could add an option to the 'sspi' auth method to check the group
membership, rather than having this done in pg_ident.conf, which is
really intended to allow mapping between system usernames and PG
usernames which are different, not really for controlling authentication
based on group membership when the username is the same.
Russell, thoughts on that..?
Thanks,
Stephen
