From: | Julian Markwort <julian(dot)markwort(at)uni-muenster(dot)de> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, arne(dot)scheffer(at)uni-muenster(dot)de |
Subject: | Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full |
Date: | 2018-04-13 15:48:41 |
Message-ID: | 1523634521.12410.14.camel@uni-muenster.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
clientcert_verify_full_v04.patch | text/x-patch | 13.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-04-13 15:55:22 | Re: Overcoming SELECT ... FOR UPDATE permission restrictions |
Previous Message | Andres Freund | 2018-04-13 15:41:39 | Re: Postgres stucks in deadlock detection |