Date: Fri, 27 Feb 2015 19:37:49 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Providing catalog view to pg_hba.conf file - Patch
 submission
Message-ID: <20150228003749.GU29780@tamriel.snowman.net>
References: <54C8156E.1080500@BlueTreble.com>
 <CAJrrPGcFk9_svvipFJeLBrVJYOmq6uNy38NsT8jtfo6Bks5RYw@mail.gmail.com>
 <54C95C4B.2080901@BlueTreble.com>
 <54F09D68.2090700@2ndquadrant.com>
 <20150227165950.GP29780@tamriel.snowman.net>
 <CAFj8pRBo6n4gEQV8J72R0_iXiCa-kZ+j1Ecwk+LrjZRJFN4PhQ@mail.gmail.com>
 <20150227183236.GQ29780@tamriel.snowman.net>
 <CAFj8pRD0GmDAf-4M8U=JyuDRUn5n1W3HCbL2oaKDbasLKwU4zw@mail.gmail.com>
 <20150227195529.GS29780@tamriel.snowman.net>
 <12545.1425072391@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="+hGRuEBnBrDfOHI9"
Content-Disposition: inline
In-Reply-To: <12545.1425072391@sss.pgh.pa.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--+hGRuEBnBrDfOHI9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Right, we also need a view (or function, or both) which provides what
> > the *active* configuration of the running postmaster is.  This is
> > exactly what I was proposing (or what I was intending to, at least) with
> > pg_hba_active, so, again, I think we're in agreement here.
>=20
> I think that's going to be a lot harder than you realize, and it will have
> undesirable security implications, in that whatever you do to expose the
> postmaster's internal state to backends will also make it visible to other
> onlookers; not to mention probably adding new failure modes.

I had been considering what it'd take (and certainly appreciated that
it's not trivial to look at the postmaster post-fork) but had also been
thinking a simpler approach might be possible (one which doesn't involve
*directly* looking at the postmaster config)- we could probably
reasonably consider whatever the backend has currently is the same as
the active configuration, provided we reload the pg_hba.conf into the
backends when a sighup is sent, just as we do with postgresql.conf.

I understand that there may be objections to that on the basis that it's
work that's (other than for this case) basically useless, but then
again, it's not like we anticipate reloads happening with a high
frequency or that we expect loading these files to take all that long.

The original patch only went off of what was in place when the backend
was started from the postmaster and the later patch changed it to just
always show what was currently in the pg_hba.conf file, but what
everyone on this thread (except those worried more about the
implementation and less about the capability) expects and wants is
"pg_settings, but for pg_hba".  The way we get that is to do it exactly
the same as how we handle pg_settings.

> I think the proposed mechanism (ie read and return the current contents of
> the file) is just fine, and we should stop there rather than engineering
> this to death.  We've survived twenty years with *no* feature of this
> sort, how is it suddenly essential that we expose postmaster internal
> state?

Perhaps I'm missing something, but I really don't see it to be a huge
deal to just reload pg_hba.conf in the backends when a sighup is done,
which would provide pg_settings-like results (ignoring that you can set
GUCs directly in the backend, of course), with two ways through the
function which loads the file- one which actually updates the global
setting in the backend during a sighup, and one which provides the
results in variables passed in by the caller (or similar) and allows
returning the contents of the current pg_hba.conf as parsed in an SRF.

	Thanks!

		Stephen

--+hGRuEBnBrDfOHI9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJU8Q3dAAoJEO1sijiDR2RVraMP/jLxLwZ7NTlcLp129E2xN5Sd
KBAHNn4OaOXRRnw/4/j5xHf+dT3xs34Fmhr65+4McQO19DFUXjQeBB/l79xyIg73
I0ANRiCyO3Dr2Zt07DagcaVY2RKXeZ+bBhRyDPHvZbELG+OLSELXzHQu5qQPoydm
V2Blj9vYAX7ilL9ZcAGcOaPhchh7aCbWUftAeBUV3YfFWq4baIcqMD6emNnKSoo5
vo5F0rcRB9sI8ny49AhbT0RcaRlDgSavwvLZyzLFn4B4RWUw7UbN/xaztsLoIY70
gxsjZPn8ZqzzX9QBaS5+VBQkUuVQsVcmxG4yVro4XalpD5Y7AMVAc/3VbmJa0guR
+XTb4THg5YHcx5vdpX8Gh0w8tncp3KmFBJnHcLbfvgdLvxuxhtvvHDwpGrieHNat
ChKXYNgWvWg45CTWNaskx1A0rCCD6ZRUki2d8Gic7Nh1GxJRpPApLtXObuLyaaXb
r0NTRJ1+aDft/kaK5IaHBfKbQH4k6Qg7a+BFgCySC09o46iW3oa00JqdnWbBkt/q
c7lFt9SIYoebbeb1AeD8NvvQQAhoUsXKn9W0Jsv7poHZJ+VYAx3xD+86hnmw3Zse
m/TTxy6rxvth+oLV3RFzocSpQNOzm/p2BmrsiKayPLQOXTZqws2TlqV0UGM5W3W3
PSZWzofPlpElbJh/ciyn
=INYi
-----END PGP SIGNATURE-----

--+hGRuEBnBrDfOHI9--