Re: Disabling trust/ident authentication configure option - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Disabling trust/ident authentication configure option
Date
Msg-id 20150520203335.GN26667@tamriel.snowman.net
Whole thread Raw
In response to Re: Disabling trust/ident authentication configure option  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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.

Apologies for the confusion- the 'development type of environment' I was
referring to above is the environment where our default from-source
pg_hba.conf is installed: when doing *PostgreSQL* development.  I don't
see the use-case for using 'trust' when doing application development
with PG as a database.  I've certainly not used it before and when I've
found it in places that I've gone, after explaining how it actually
works, everyone I've worked with has either changed it or made plans to
do so.

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

I agree with this, as mentioned up-thread.  Having a way to support
single-user development / running of PG would really need to exist
before we could encourage getting rid of '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.

I don't see a real proposal for it either; I was simply trying to
outline a path forward, one which I would agree with, rather than
simply saying "no, never."
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Next
From: Tom Lane
Date:
Subject: Re: ERROR: cannot GetMultiXactIdMembers() during recovery