From: Robbie Harwood <rharwood@redhat.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
        Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH v12] GSSAPI encryption support
In-Reply-To: 
 <CAB7nPqQpNXMVLDX4XGjcoQPzRFF-Hj5MDse=ac9jZP91X0cYcw@mail.gmail.com>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <jlgy48ssyvl.fsf@thriss.redhat.com>
 <20160406112105.GG10850@tamriel.snowman.net>
 <jlg1t6isftk.fsf@thriss.redhat.com> <1530.1459977031@sss.pgh.pa.us>
 <jlgy48qqt86.fsf@thriss.redhat.com> <5486.1459984857@sss.pgh.pa.us>
 <CAB7nPqRPK1f4oAStwsy_Ty_Cjjo8U50HF0bRZi86my7va4nVdg@mail.gmail.com>
 <jlgk2hq3uvr.fsf@thriss.redhat.com> <jlg7fc91lko.fsf@thriss.redhat.com>
 <CAB7nPqSmq1tuVGoVQXVb86y9SoaM-wcMDxHD1of9dGc54QYNSQ@mail.gmail.com>
 <jlg7fc8fmq7.fsf@thriss.redhat.com>
 <CAB7nPqQpNXMVLDX4XGjcoQPzRFF-Hj5MDse=ac9jZP91X0cYcw@mail.gmail.com>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Wed, 27 Jul 2016 13:12:27 -0400
Message-ID: <jlgpopzhuo4.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 Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood <rharwood@redhat.com> wrote:
>> Michael Paquier <michael.paquier@gmail.com> writes:
>>
>> So there's a connection setting `sslmode` that we'll want something
>> similar to here (`gssapimode` or so).  `sslmode` has six settings, but I
>> think we only need three for GSSAPI: "disable", "allow", and "prefer"
>> (which presumably would be the default).
>
> Seeing the debate regarding sslmode these days, I would not say that
> "prefer" would be the default, but that's an implementation detail.
>
>> Lets suppose we're working with "prefer".  GSSAPI will itself check two
>> places for credentials: client keytab and ccache.  But if we don't find
>> credentials there, we as the client have two options on how to proceed.
>>
>> - First, we could prompt for a password (and then call
>>   gss_acquire_cred_with_password() to get credentials), presumably with
>>   an empty password meaning to skip GSSAPI.  My memory is that the
>>   current behavior for GSSAPI auth-only is to prompt for password if we
>>   don't find credentials (and if it isn't, there's no reason not to
>>   unless we're opposed to handling the password).
>>
>> - Second, we could skip GSSAPI and proceed with the next connection
>>   method.  This might be confusing if the user is then prompted for a
>>   password and expects it to be for GSSAPI, but we could probably make
>>   it sensible.  I think I prefer the first option.
>
> Ah, right. I completely forgot that GSSAPI had its own handling of
> passwords for users registered to it...
>
> Isn't this distinction a good point for not implementing "prefer",
> "allow" or any equivalents? By that I mean that we should not have any
> GSS connection mode that fallbacks to something else if the first one
> fails. So we would live with the two following modes:
> - "disable", to only try a non-GSS connection
> - "enable", or "require", to only try a GSS connection.
> That seems quite acceptable to me as a first implementation to just
> have that.

If it is the password management that is scary here, we could have a
prefer-type mode which does not prompt, but only uses existing
credentials.  Or we could opt to never prompt, which is totally valid.

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

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

iQIcBAEBAgAGBQJXmOt9AAoJECUy+RdqlaRCN9IP/iupVOSvZ0vmpAnUv1pGU2Lw
MPcltOWLoDb+Dqw1/EGp0fjmXmrafdeC2mPnEBY81fW9dAdb9U/R22Wt50awBomg
h/0qVr55Tr3yeR4tN1Mp2FWx77pUyNu9egX7OWgzjVFxeJMerHsOQ2T2zK6YlXcO
rY41l7tlIgfIaE1dPgpGzE9Vuk7y4/o6QoqBtugnUjOnTqWLUT7s+GY9DAtPDRcM
rrxNoT+ohQQfb8xOP3gTAL9Z+lqP90Fj2rA7z5mt1IITyu2xC3SYHegwJfhqda/D
Ma8Bm51Kqd8TxBa3mdcxSCv9bxXVGfMzN3HAU2pQsfihTCg9A95/ieQduzGQFUfm
HdZs1h67Sqfh5flqvQIkEYa2y0zIbvJmS+YtakDUUWJSff4pD0TKYx8MUnE+iAx6
BMRL8REG1mDn8o3TimDYNvNEQP9OJnwMuTZUD+amKYHXRY2UbKjGNr073CCXNzQf
y4QLT9mSJ1qGdM9+zPfxde6FJrpSsCJXFPMvybyUNGsh2TCMSsRSLV/wgI0yT5KD
sTeU60xNP23hDsnk8RyHUd+daV2izunctmc8VSOBEnDB3IlQYqHzyID09Fhy+BLM
c17Q68oLwvJft8DVpQlaMFfcayZvXTb/sUMQZx7BLMQzxfiiSKXprEqNzjf5YpPI
Rz7nEfZMKw32xtKX1JUE
=zeWT
-----END PGP SIGNATURE-----
--=-=-=--