Re: [PATCH v10] GSSAPI encryption support

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:

> On Fri, Apr 1, 2016 at 12:31 PM, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
>
>> - Fixed buffering of large replies on the serverside. This should fix
>> the traceback that was being seen. The issue had to do with the
>> difference between the server and client calling conventions for the
>> _read and _write functions.
>
> This does not fix the issue. I am still able to crash the server with
> the same trace.

Interesting. I guess I'll keep trying to reproduce this.

>> - Move gss_encrypt out of the GUCs and into connection-specific logic.
>> Thanks to Tom Lane for pointing me in the right direction here.
>
> + /* delay processing until after AUTH_REQ_OK has been sent */
> + if (port->gss->gss_encrypt != NULL)
> + port->gss->encrypt = !strcmp(port->gss->gss_encrypt, "on");
>
> You should use parse_bool here, because contrary to libpq, clients
> should be able to use other values like "1", "0", "off", 'N', 'Y',
> etc.

Missed that function somehow. Will fix.

>> - Replace writev() with two calls to _raw_write(). I'm not attached to
>> this design; if someone has a preference for allocating a buffer and
>> making a single write from that, I could be persuaded. I don't know
>> what the performance tradeoffs are.
>
> Relying on pqsecure_raw_write and pqsecure_raw_read is a better bet
> IMO, there is already some low-level error handling.

Indeed, it looks like it should especially lead to better behavior on
Windows.

> static ConfigVariable *ProcessConfigFileInternal(GucContext context,
> bool applySettings, int elevel);
>
> -
> /*
>
> Spurious noise.

Indeed, will fix.