Re: [PATCH v12] GSSAPI encryption support

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

> On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
>> Michael Paquier <michael(dot)paquier(at)gmail(dot)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.