| 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
| 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 |