Re: Disabling trust/ident authentication configure option

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Volker Aßmann <volker(dot)assmann(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Disabling trust/ident authentication configure option
Date: 2015-05-18 15:50:16
Message-ID: 555A0A38.40405@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 05/18/2015 11:36 AM, Jim Nasby wrote:
> On 5/17/15 10:58 PM, Josh Berkus wrote:
>> The goal here was stated to preventing authentication misconfiguration
>> by shortsighted admins who have superuser access and the ability to
>> change pg_hba.conf. This is tantamount to giving someone a gun and
>> bullets, but expecting duct tape across the cartridge slot to prevent
>> them from loading or using the gun.
>
> The idea is to prevent *accidental* misconfiguration, not to try and
> permanently lock them out. IE: make them think before allowing them to
> just do something silly. Disabling auth methods at compile time seems
> a very reasonable way to accomplish that.

It's not more secure or more useful if it increases substantially the
difficulty and disruption of recovering from misconfiguration, whether
accidental or not. Disabling both trust and peer would do just that,
without significantly impeding malicious users.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryan Pedela 2015-05-18 15:57:41 Re: jsonb concatenate operator's semantics seem questionable
Previous Message Jim Nasby 2015-05-18 15:48:45 Re: Making the regression tests halt to attach a debugger