Re: Disabling trust/ident authentication configure option

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

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> I don't agree with this either. Providing a "bypass all authentication"
> configuration option really isn't a good thing. Why don't packagers use
> our default pg_hba.conf? Because it only makes sense in a development
> type of environment. I'd argue the same is true for 'trust'.

Sure. And the problem is that development environments are a perfectly
common and respectable use-case. I cannot see Red Hat, for example,
shipping a Postgres that's built (not merely configured by user-changeable
config files, but hard-wired) to be unfriendly to developers.

If we could get to a point where there is another way that is superior
to "trust" even for single-user development environments, then maybe
it would be useful to try to persuade packagers to disable "trust".
But I don't even see a proposal for such a thing, let alone a track record
showing that nobody needs "trust". And you really have got to get to the
point of being able to argue that *nobody* needs trust, not that some
use-cases don't need it, before you will impress most packagers.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-20 20:03:48 Re: Problems with question marks in operators (JDBC, ECPG, ...)
Previous Message Andres Freund 2015-05-20 19:52:07 Re: anole: assorted stability problems