Re: Initial release notes created for 9.6

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christian Ullrich <chris(at)chrullrich(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Initial release notes created for 9.6
Date: 2016-05-06 20:07:35
Message-ID: 8390.1462565255@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christian Ullrich <chris(at)chrullrich(dot)net> writes:
> * Tom Lane wrote:
> + <para>
> + Add new SSPI authentication parameters <varname>compat_realm</>
> + and <varname>upn_usename</>, to make it possible to make SSPI
> + work more like GSSAPI (Christian Ullrich)
> + </para>

> It is upn_username, not usename. Typo in the commit message.

> "Make SSPI work more like GSSAPI" reads like it changed authentication
> behavior in some fundamental way, and as if SSPI did not work like
> GSSAPI without it. The difference in behavior of include_realm between
> GSSAPI and SSPI is not caused by SSPI, but is an implementation detail
> on our end.

> I suggest writing "use the Kerberos realm name for authentication
> instead of the NetBIOS name" either in place of the existing description
> or together with it.

OK, how about this:

<para>
Add new SSPI authentication parameters <varname>compat_realm</>
and <varname>upn_username</>, to control whether NetBIOS or Kerberos
realm names and user names are used during SSPI authentication
(Christian Ullrich)
</para>

BTW, I went to read the descriptions of those parameters again, and this
one seems a bit confusing:

<varlistentry>
<term><literal>compat_realm</literal></term>
<listitem>
<para>
If set to 1, the domain's SAM-compatible name (also known as the
NetBIOS name) is used for the <literal>include_realm</literal>
option. This is the default. If set to 0, the true realm name from
the Kerberos user principal name is used.
</para>
<para>
Do not enable this option unless your server runs under a domain
account (this includes virtual service accounts on a domain member
system) and all clients authenticating through SSPI are also using
domain accounts, or authentication will fail.
</para>
</listitem>
</varlistentry>

To my mind, an option that's set to 1 is "enabled". Should the second
para read "Do not disable ..."? Or maybe we should reverse the sense
of the flag, so that the default state can be 0 == disabled?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-05-06 20:07:54 Re: pgsql: Add TAP tests for pg_dump
Previous Message Alvaro Herrera 2016-05-06 20:03:33 Re: Feature request: make cluster_name GUC useful for psql prompts