From: Robbie Harwood <rharwood@redhat.com>
To: Michael Paquier <michael.paquier@gmail.com>,
        David Steele <david@pgmasters.net>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH v6] GSSAPI encryption support
In-Reply-To: 
 <CAB7nPqTjnLWBOepE+Oy5WZBjcq7sRJ9_uKvvXuThst9dvBxkZQ@mail.gmail.com>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <jlgegbkmvxl.fsf@thriss.redhat.com> <56E81852.1060005@pgmasters.net>
 <CAB7nPqTjnLWBOepE+Oy5WZBjcq7sRJ9_uKvvXuThst9dvBxkZQ@mail.gmail.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Tue, 15 Mar 2016 15:41:14 -0400
Message-ID: <jlgtwk7il5x.fsf@thriss.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--=-=-=
Content-Type: text/plain

Michael Paquier <michael.paquier@gmail.com> writes:

> On Tue, Mar 15, 2016 at 3:12 PM, David Steele <david@pgmasters.net> wrote:
>> On 3/8/16 5:44 PM, Robbie Harwood wrote:
>>> Here's yet another version of GSSAPI encryption support.
>>
>> This looks far more stable than last versions, cool to see the
>> progress. pgbench -C does not complain on my side so that's a good
>> thing. This is not yet a detailed review, there are a couple of
>> things that I find strange in what you did and are potential subject
>> to bugs, but I need a bit of time to let that mature a bit. This is
>> not something yet committable, but I really like the direction that
>> the patch is taking.

Thanks!  I must admit a preference for receiving all feedback at once
(reduces back-and-forth overhead), but if you feel there are still
design-type problems then that's very reasonable.  (I also admit to
feeling the pressure of feature freeze in less than a month.)

> For now, regarding 0002:
>     /*
> -    * Flush message so client will see it, except for AUTH_REQ_OK, which need
> -    * not be sent until we are ready for queries.
> +    * In most cases, we do not need to send AUTH_REQ_OK until we are ready
> +    * for queries, but if we are doing GSSAPI encryption that request must go
> +    * out now.
>      */
> -   if (areq != AUTH_REQ_OK)
> -       pq_flush();
> +   pq_flush();
> Er, this sends unconditionally the message without caring about the
> protocol, and so this is incorrect, no?

My impression from reading the old version of the comment above it was
that on other protocols it could go either way.  I think last time I
made it conditional; I can do so again if it is desired.  It's certainly
not /incorrect/ to send it immediately; there's just a question of
performance by minimizing the number of writes as far as I can tell.

> +#ifdef ENABLE_GSS
> +       if (conn->gss->buf.data)
> +           pfree(conn->gss->buf.data);
> +       if (conn->gss->writebuf.data)
> +           pfree(conn->gss->writebuf.data);
> +#endif
> You should use resetStringInfo here.

That will leak since resetStringInfo() doesn't free the underlying
representation.

>> OK, everything seems to be working fine with a 9.6 client and server so
>> next I tested older clients and I got this error:
>>
>> $ /usr/lib/postgresql/9.1/bin/psql -h localhost \
>>   -U vagrant@PGMASTERS.NET postgres
>> psql: FATAL:  GSSAPI did no provide required flags
>>
>> There's a small typo in the error message, BTW.

Thanks, will fix.  I forgot that MIT doesn't provide GSS_C_REPLAY_FLAG
and GSS_C_SEQUENCE_FLAG by default.  Removing those from auth.c should
temporarily resolve the problem, which is what I'll do in the next
version.  (Tested with MIT krb5.)

On the subject of older code, I realized (one of those wake up in the
middle of the night-type moments) that the old server has a potential
problem with new clients now in that we try to decrypt the "help I don't
recognize connection parameter gss_encrypt" error message.  v8 will have
some sort of a fix, though I don't know what yet.  The only thing I've
come up with so far is to have the client decrypt check the first time
through for packets beginning with 'E'.  Pretty much anything I can do
will end up being a poor substitute for being at the protocol layer
anyway.

> And in 0003, the previous error is caused by that:
> +   target_flags = GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG |
> +       GSS_C_SEQUENCE_FLAG | GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG;
> +   if ((gflags & target_flags) != target_flags)
> +   {
> +       ereport(FATAL, (errmsg("GSSAPI did no provide required flags")));
> +       return STATUS_ERROR;
> +   }
> Yeah, this is a recipe for protocol incompatibility and here the
> connection context is not yet fully defined I believe. We need to be
> careful.

Nope, it's done.  This is happening immediately prior to username
checks.  By the time we exit the do/while the context is fully
complete.

> -       maj_stat = gss_accept_sec_context(
> -                                         &min_stat,
> +       maj_stat = gss_accept_sec_context(&min_stat,
>
> This is just noise.

You're not wrong, though I do think it makes the code more readable by
enforcing style and this is a "cleanup" commit.  I'll take it out if it
bothers you.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW6GVbAAoJECUy+RdqlaRCzRMQAKmEoJDT98cMoR85p4kcTLV4
LbuGl0DanWATPT+x+RgXJUVA7ShSIphKogI/TYNL7AdiKXxYMr5VCiU5rdgokQJL
1PQJc1epVO5DdgISLukOXdknQFT56b6tIO1/U/L8fPpucDShSWXzlpVHG6vm1O+b
SFSn3OoeVZ6Q0BZ5I94xDdISTDWfwHCXTcH7X0tTjl8Ce9A4fc3gxJYnFjBS6vUO
ubHNcfaMTq5UMtNcfRfOSpWOpkdOs8MRNhsuVRUFTRHJ8GYLgWfpP116b9i2FdFU
GOua+EMo1lK8UuEy2AXw9Jmj1Q32BvQ/Ho7G0l9rtEIetlE3E1E1BwGSD9XHMVo5
faCkjO2GhJbqyu/SHhSngz4a/wjiTFLWU7gAZz+mp1a08460uR4UL5z2oiYTTGSN
XwykVDoHwHIrgj9YDn0L9GwvHbWQMbnz+ef0hAgR2zMLNI/cJYZcbVkZYan/o5fY
smsJgxP59EMR9SWwsNY/YvE/Nx1ZnXQjbFrw5nZgmU7JWQLlZKPsavxR4LGgUPg7
94ShfZ5Sk+1G/ZwGkvitRiR1NHmPmPrI9d97h79oaCPUczsOrPnVJkQ+mFsCkBZF
8yKeGP0VswonYf8hVmZX9yHbFrRDPt4lHahQxdZYj7NHInjsg1iC2eKJM8gz3IY7
pNnXVyfP6Wm0uoS551mQ
=EiI+
-----END PGP SIGNATURE-----
--=-=-=--