From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Volker Aßmann <volker(dot)assmann(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, 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-23 21:15:32 |
Message-ID: | 3337.1432415732@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> So from my perspective anything which requires going off standard
> PostgreSQL packages, and encourages users to go off standard PostgreSQL
> packages, is a actually a fairly high cost even if the code is
> non-invasive.
Agreed.
> I would be more open to a GUC which limited the auth
> mechansisms available (requiring restart to change), for example, than a
> compile flag.
But how would that fix Volker's scenario? GUCs are even easier to change
than pg_hba.conf --- in fact, now that we have ALTER SYSTEM, you couldn't
even use configuration management of postgresql.conf to prevent somebody
from altering the value of such a GUC.
I think the real bottom line is this: our code is not designed to prevent
DBAs from doing things that are contrary to local policy, and I for one
am not terribly excited about trying to make it do so. The list of things
that might be contrary to local policy is just too long, and the number
of ways a DBA might get around any particular restriction is too great.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2015-05-23 21:36:41 | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Previous Message | Tom Lane | 2015-05-23 20:33:29 | Re: fsync-pgdata-on-recovery tries to write to more files than previously |