Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bruce(at)momjian(dot)us
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: "cert" + clientcert=verify-ca in pg_hba.conf?
Date: 2020-08-27 07:09:25
Message-ID: 20200827.160925.279969179228617520.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian <bruce(at)momjian(dot)us> wrote in
bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <bruce(at)momjian(dot)us> wrote in
> > > > Because we think we need any named value for every alternatives
> > > > including the default value?
> > >
> > > Well, not putting clientcert at all gives the default behavior, so why
> > > have clientcert=no-verify?
> >
> > clientcert=verify-ca or verify-full don't allow absence of client
> > certificate. We need an option to allow the absence.
>
> Isn't the option not specifying clientcert? Here are some valid
> pg_hba.conf lines:

Sorry for the ambiguity. Perhaps I understand that we talked at
different objects. I was mentioning about the option value that is
stored *internally*, concretely the values for the struct member
port->hba->clientcert. You are talking about the descriptive option in
pg_hba.conf.

Does the following discussion make sense?

We need to use the default value zero (=clientCertOff) for
port->hba->clientcert to tell server to omit checking against CA if
cert is not given. I suppose that the value clientCertOff is labeled
as "no-verify" since someone who developed this thought that that
choice needs to be explicitly describable in pg_hba.conf. And my
discussion was following that decision.

I understand that the label "no-verify" is not essential to specify
the behavior, so I don't object to removing "no-verify" label itself
if no one oppose to remove it.

My point here is just "are we OK to remove it?"

> It is my understanding that the last two lines are the same. Why isn't
> it sufficient to just tell users not to specify clientcert if they want
> the default behavior? You can do:
>
> host all all 192.168.0.0/16 ident map=omicron
>
> but there is no way to specify the default map value of 'no map', so why
> have one for clientcert?

The difference from clientcert is that it gives an arbitrary name that
points to a defined mapping, not a choice from an defined
enumeration.

> > > Well, sslmode=prefer gives encryption without identification.
> > > clientcert=no-verify has no value because it is just an optional CA
> > > check that has no value because optional authentication is useless. It
> >
> > The point of the option is not to do optional CA check if possible,
> > but to allow absence of client cert. We need to have that mode
> > regardless of named or not named, and I believe we usually provide a
> > name for default mode.
>
> Uh, see above --- not really. The absense of the option is the default
> action.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-08-27 07:46:15 Re: Typo in procarray.c comment about GlobalVisDataRels
Previous Message Asim Praveen 2020-08-27 06:59:13 Re: SyncRepLock acquired exclusively in default configuration