Re: [PATCH v12] GSSAPI encryption support

Поиск
Список
Период
Сортировка
От Robbie Harwood
Тема Re: [PATCH v12] GSSAPI encryption support
Дата
Msg-id jlgpopzhuo4.fsf@thriss.redhat.com
обсуждение исходный текст
Ответ на Re: [PATCH v12] GSSAPI encryption support  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [PATCH v12] GSSAPI encryption support  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Why we lost Uber as a user
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Macro customizable hashtable / bitmapscan & aggregation perf