Re: [PATCH v20] GSSAPI encryption support

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [PATCH v20] GSSAPI encryption support
Дата
Msg-id 20190405213745.GR6197@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [PATCH v20] GSSAPI encryption support  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [PATCH v20] GSSAPI encryption support  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Greetings,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 2019-04-05 14:48, Stephen Frost wrote:
> > On a failure to set up an encrypted connection, we'll actually fall back
> > to a non-encrypted one using GSSAPI *just* for authentication, which is> why I was asking if this worked before the
encryptionpatch went in. 
>
> The tests have always worked before.  I've run them probably hundreds of
> times.

Ok.

> > Also, which of the tests are still failing, exactly?  The authentication
> > ones or the encryption ones or both?
>
> Only the encryption ones:
>
> not ok 1 - GSS-encrypted access
>
> #   Failed test 'GSS-encrypted access'
> #   at t/002_enc.pl line 170.
> #          got: '2'
> #     expected: '0'
> ok 2 - GSS encryption disabled
> not ok 3 - GSS encryption without auth
>
> #   Failed test 'GSS encryption without auth'
> #   at t/002_enc.pl line 170.
> #          got: '2'
> #     expected: '0'
> not ok 4 - GSS unencrypted fallback
>
> #   Failed test 'GSS unencrypted fallback'
> #   at t/002_enc.pl line 170.
> #          got: '2'
> #     expected: '0'
> ok 5 - GSS unencrypted fallback prevention

So, looking back at the error message you got:

FATAL:  GSSAPI context error
DETAIL:   Miscellaneous failure (see text): Decrypt integrity check
failed for checksum type hmac-sha1-96-aes256, key type
aes256-cts-hmac-sha1-96

FATAL:  accepting GSS security context failed
DETAIL:   Miscellaneous failure (see text): Decrypt integrity check
failed for checksum type hmac-sha1-96-aes256, key type
aes256-cts-hmac-sha1-96

(assuming that's still what you're getting..?)

What this is saying is basically that the key that the PG server is
using from its keytab and the key used to encrypt the ticket that the
user has (from the KDC) don't match up.

I wonder if somehow the keytab file that the server is using isn't
getting destroyed between the two test runs and so you're ending up with
the server using the key from the old KDC, while the user is using the
new one..?  Or something is equally going wrong in the tests.

Could you try doing something like removing the 001_auth.pl, moving the
002_enc.pl to 001_enc.pl, double-check that everything is cleaned up and
that there aren't any old PG servers running, et al, and re-try that
way?

I've also reached out to some colleagues about having one of them test
with MacOS.  What version are you on..?

Thanks!

Stephen

Вложения

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Re: Copy function for logical replication slots
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum