Thread: Making pg_config and pg_controldata output available via SQL
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? -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
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