Skip site navigation (1) Skip section navigation (2)

Re: Unfriendly handling of pg_hba SSL options with SSL off

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unfriendly handling of pg_hba SSL options with SSL off
Date: 2011-04-25 17:12:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Apr 25, 2011 at 19:11, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'm inclined to think that the correct fix is to make parse_hba_line,
>>> where it first realizes the line is "hostssl", check not only that SSL
>>> support is compiled but that it's turned on.
>> It's not clear to me what behavior you are proposing.  Would we
>> disregard the hostssl line or treat it as an error?
> Sorry, I wasn't clear.  I meant to throw an error.  We already do throw
> an error if you put hostssl in pg_hba.conf when SSL support wasn't
> compiled at all.  Why shouldn't we throw an error if it's compiled but
> not turned on?
> Or we could go in the direction of making hostssl lines be a silent
> no-op in both cases, but that doesn't seem like especially user-friendly
> design to me.  We don't treat any other cases in pg_hba.conf comparably

We need to be very careful about ignoring *anything* in pg_hba.conf,
since it's security configuration. Doing it silently is even worse..

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-04-25 17:16:49
Subject: Re: branching for 9.2devel
Previous:From: David BlewettDate: 2011-04-25 17:12:36
Subject: Re: branching for 9.2devel

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group