Re: host and hostssl equivalence in pg_hba.conf

From: Jon Jensen <jon(at)endpoint(dot)com>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: host and hostssl equivalence in pg_hba.conf
Date: 2003-06-10 13:46:04
Message-ID: Pine.LNX.4.50.0306101341520.1335-100000@louche.swelter.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Tue, 10 Jun 2003, Nigel J. Andrews wrote:

> How do people feel about changing matching for host and hostssl to be such that
> a plain host line in pg_hba.conf does not allow a SSL connection but requires
> the hostssl specifier?

Nigel,

We had discussed overhauling the connection settings on both client and
server to cover all needs, along these lines:

> Date: Tue, 7 Jan 2003 16:07:58 -0500 (EST)
> From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
> To: Peter Eisentraut <peter_e(at)gmx(dot)net>
> Cc: Jon Jensen <jon(at)endpoint(dot)com>, pgsql-patches(at)postgresql(dot)org
> Subject: Re: [PATCHES] Refuse SSL patchf
>
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > > Tom thought that having conflicting REFUSESSL and REQUIRESSL directives
> > > > would be confusing, and since I dug up someone's old discussion in the
> > > > list archives of the four possible modes, we could move to that.
> > >
> > > Oh. I find two params clearer than one with meaningless numbers. :-)
> >
> > But the numeric model provides four modes (refuse ssl, prefer no ssl,
> > prefer ssl, require ssl) whereas the refuse/require combination only
> > provides three modes (refuse ssl, require ssl, and one other depending on
> > how you define it when neither is set). If you don't like numbers, make
> > them words.
>
> OK, that works:
>
> require
> prevent
> prefer
> noprefer
>
> This allows us to subsume PGREQUIRE_SSL into the new variable. Do we
> still need additional functionality in pg_hba.conf? I am only asking if
> pushing these decisions out to the client makes sense?
>
> For performance reasons, it is good to push this information out to the
> clients so the proper connection method is used the first time.
>
> However, for easier maintenance, we could have all of this in
> pg_hba.conf only, and have clients try SSL first, and fall back to
> non-SSL if the server doesn't want SSL. It would require two new
> pg_hba.conf line types. We have prefer-SSL (host) and SSL-only (ssl)
> now.
>
> require (ssl)
> prevent (nossl)
> prefer (hostpreferssl)
> noprefer(host)
>
> This would change 'host' to not prefer SSL.

Unfortunately, I lived with my own local patch and forgot about making the
more general one these past five months.

This proposal would meet your needs, wouldn't it?

Jon

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-06-10 13:51:05 Re: The transaction that "happens" with function invocation
Previous Message Tom Lane 2003-06-10 13:42:16 Re: host and hostssl equivalence in pg_hba.conf

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2003-06-10 13:48:09 Re: 7.3.3 COMPILE FAILURE: pg_dump (fwd)
Previous Message Tom Lane 2003-06-10 13:45:52 Re: Function returns composite type