Re: Disabling trust/ident authentication configure option

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: 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>, Andrew Dunstan <andrew(at)dunslane(dot)net>, 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 03:58:45
Message-ID: 55596375.7070601@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Wed, May 13, 2015 at 2:18 PM, Robert Haas <robertmhaas(at)gmail(dot)com
> <mailto:robertmhaas(at)gmail(dot)com>> wrote:
> All of this is fairly far afield from the original topic of this
> thread, which was whether a configure option disabling trust + ident
> authentication would be a good idea. I said no. Then we had a bunch
> of counter-proposals:
>
> Alvaro: Support a configure switch whose value is a comma-separated
> list of authentication methods to disable.

So, I'm going to throw in why a configure option to disable "trust,
peer" is an unworkable idea.

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.

Let's say we offered a compile-time option, and then someone built a
package postgresql-9.6-secureauth.deb. So, your lazy admin is having
trouble debugging an auth problem and wants to set "trust". But they
can't. So they search on Google and figure out how to download and
install postgresql-9.6-normalauth.deb. Or, alternately, they set all
passwords to "password" or to "". Or they put .pgpass files on all
machines. Or they put the password in pgbouncer and set pgbouncer to
"trust".

You've added exactly one additional step in their way, and not a
particularly difficult one. It simply doesn't solve the problem you're
trying to solve, which is unsurprising, because technology has never
been able to solve the problem of untrustworthy humans with positions of
responsibility.

Now, if you wanted to add an audit log every time someone changes an
auth method in pg_hba.conf? I'd be all for that, I can see all kinds of
uses for that, and it might actually accomplish something effective.

If you disagree with me, well, it would be very easy to hack out the
auth methods you don't like and compile your own. It *is* open source.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-05-18 04:11:58 Re: jsonb concatenate operator's semantics seem questionable
Previous Message Josh Berkus 2015-05-18 03:41:44 Re: jsonb concatenate operator's semantics seem questionable