Making pg_config and pg_controldata output available via SQL

Joshua Tolley <eggyknap@gmail.com> writes:

I'd really like to see the data from pg_config and pg_controldata available
through SQL, such as by adding output to pg_show_all_settings(), or adding new
SRFs named something like pg_config() and pg_controldata(). Does this make as
much sense to the rest of the world as it does to me? In particular it's
useful to be able to find $libdir without requiring pg_config, as some
packagers tend not to include it in anything put the -dev packages, but all
those settings seem useful to have on hand, and in at least most cases
shouldn't be tough to expose via SQL. Comments?

I wonder whether there's a security issue there. Telling an attacker
whether you've been built with feature X seems like possibly useful
info that he couldn't otherwise get without local machine access.
In particular, we already try to avoid exposing server filesystem
path information.

regards, tom lane

On Wed, Feb 03, 2010 at 02:32:47PM -0500, Tom Lane wrote:

Joshua Tolley <eggyknap@gmail.com> writes:

I'd really like to see the data from pg_config and pg_controldata available
through SQL, such as by adding output to pg_show_all_settings(), or adding new
SRFs named something like pg_config() and pg_controldata(). Does this make as
much sense to the rest of the world as it does to me? In particular it's
useful to be able to find $libdir without requiring pg_config, as some
packagers tend not to include it in anything put the -dev packages, but all
those settings seem useful to have on hand, and in at least most cases
shouldn't be tough to expose via SQL. Comments?

I wonder whether there's a security issue there. Telling an attacker
whether you've been built with feature X seems like possibly useful
info that he couldn't otherwise get without local machine access.
In particular, we already try to avoid exposing server filesystem
path information.

I'd wondered the same thing, without spending enough time on it to come to a
conclusion beyond "perhaps making the functions executable only by superuser
would suffice".

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com