Re: Disabling trust/ident authentication configure option

From: Volker Aßmann <volker(dot)assmann(at)gmail(dot)com>
To:
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, 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-15 17:15:19
Message-ID: CAJBpAdxWQscGEJubs-KLMXYd76tspwD_b2wmgYArsYYTX5ao7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yes, I'd like to know if Alvaros suggestion would in deed achieve consensus
(possibly with Andrews addition). It looks like the most general solution
but might be some work using autoconf ...

Best regards,

Volker

On Wed, May 13, 2015 at 2:18 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, May 13, 2015 at 8:01 AM, Volker Aßmann <volker(dot)assmann(at)gmail(dot)com>
> wrote:
> > Even in this case it still means that any breach in any of the network
> > services running on your application server would immediately own your
> > database, or at least everything your application can access. This
> applies
> > even to totally unrelated services running with restricted permissions.
> > Using password or certificate based authentication at least gives you the
> > additional security of local filesystem access controls and is not much
> > harder to setup. M2M authentication is always a difficult topic as the
> > "authentication tokens" have to be secured but I would agree that a more
> > specific / secure method than "disable-all-authentication" would be
> > preferable.
>
> Sure, opinions on the best way to do any given thing are going to
> vary, and nobody's trying to prevent you from configuring your
> instances of PostgreSQL however you like. The email to which I was
> responding was suggesting limiting MY ability to set up MY instances
> of PostgreSQL the way I like. And I'm opposed to that.
>
> 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.
> Peter: Generalized hardening facility.
> Andrew: Like what Alvaro said, but require at least one of trust +
> peer to remain enabled so people can't hose themselves.
> Andrew, v2: Rip out RFC1413 ident authentication completely.
> Stephen: Require a command-line option to use trust auth.
>
> There's clearly no consensus on any of these proposals, and most of
> them don't address your original requirement anyway, though Alvaro's
> would. I guess the point is that nothing is going to get changed
> here on one person's say-so if other people don't agree, so if you
> want to get something done, you're going to need to pick something
> that can achieve consensus and then implement that. Also, anything
> you want to get done is certainly going to be in 9.6 at the earliest,
> because the time for 9.5 proposals has already come and gone.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-05-15 17:29:43 Re: multivariate statistics / patch v6
Previous Message Tom Lane 2015-05-15 17:09:03 Re: WALWriteLock contention