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