Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

Поиск
Список
Период
Сортировка
От Julian Markwort
Тема Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full
Дата
Msg-id 1523634521.12410.14.camel@uni-muenster.de
обсуждение исходный текст
Ответ на Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Tue, 2018-04-10 at 18:35 +0200, Magnus Hagander wrote:
As Peter mentionde, there are in src/test/ssl. I forgot about those, but yes, it would be useful to have that.
I've added three tests:
- verify-full specified, CN and username match -- should connect ok
- verify-full specified, CN and username do not match -- should fail
- verify-ca specified, CN and username do not match -- should connect ok (This is current behaviour)

That depends on your authenticaiton method. Specifically for passwords, what happens is there are actually two separate connections -- the first one with no password supplied, and the second one with a password in it.
Makes sense.
We could directly reject the connection after the first one and not ask for a password. I'm not sure if that's better though -- that would leak the information on *why* we rejected the connection.
This wouldn't be desirable, I think...
Most applications will probably supply the password in the connection string anyway, so there would be only one connection, right?

It might definitely be worth shorting it yeah. For one, we can just use "cn" :) 
I've shortened the clientcert=verify-full specific error-message to say:
"certificate validation (clientcert=verify-full) failed for user \"%s\": CN mismatch"


slightly offtopic opinion:
While creating the test cases, I stumbled upon the problem of missing depencies to run the tests...
It's complicated enough that the binaries used by these perl tests are not named similar to the packages which provide them (the 'prove' binary is supplied by 'Test-Harness'), so maybe in the interest of providing a lower entry-barrier to running these tests, we could give a more detailed error message in the configure script, when using --enable-tap-tests ?


Julian
Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Postgres stucks in deadlock detection
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Overcoming SELECT ... FOR UPDATE permission restrictions