Re: Unfriendly handling of pg_hba SSL options with SSL off - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Unfriendly handling of pg_hba SSL options with SSL off
Date
Msg-id BANLkTinote9fDF4qeAGR7S=z-TWNKgNA4A@mail.gmail.com
Whole thread Raw
In response to Re: Unfriendly handling of pg_hba SSL options with SSL off  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unfriendly handling of pg_hba SSL options with SSL off  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Apr 25, 2011 at 19:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Apr 25, 2011 at 18:59, Robert Haas <robertmhaas@gmail.com> wrote:
>>> It's not clear to me what behavior you are proposing.  Would we
>>> disregard the hostssl line or treat it as an error?
>
>> It would absolutely have to be treat it as an error. another option
>> would be to throw a more specific warning at that place, and keep the
>> rest of the code the same.
>
>> We can't *ignore* hostssl rows in ssl=off mode, that would be an easy
>> way for an admin to set up a system they thought was secure but
>> isn't...
>
> No, I don't see that it's a security hole.  What would happen if the
> line is ignored is you couldn't make connections with it.  I think you
> are positing that it'd be a potential security problem if a connection
> attempt fell through that line and then succeeded with some later line
> that had less-desirable properties --- but if your pg_hba.conf contents
> are like that, you already have issues, because a non-SSL-enabled client
> is going to reach that later line anyway.

Good point.


> Nonetheless, it's extremely confusing to the admin to ignore such a
> line, and that's not a good thing in any security-sensitive context.

Yeah, better make any misconfiguration very clear - let's throw an error.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Unfriendly handling of pg_hba SSL options with SSL off
Next
From: Robert Haas
Date:
Subject: Re: Foreign table permissions and cloning