| 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: | Whole Thread | Raw Message | 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 |