Security implications of config-file-location patch - Mailing list pgsql-hackers

From Tom Lane
Subject Security implications of config-file-location patch
Date
Msg-id 27029.1097200532@sss.pgh.pa.us
Whole thread Raw
Responses Re: Security implications of config-file-location patch
Re: Security implications of config-file-location patch
List pgsql-hackers
In prior versions of Postgres, it has never been possible to remotely
find out the data directory location being used by the postmaster
(at least not without hacking some C code, which only superusers may
do).

You can make about equally good arguments that this is a bug or that
it's a feature:

BUG: it would be handy to be able to find that out remotely, especially
when you are admin for many postmasters and have forgotten which is
which.

FEATURE: ordinary users should not need to know this, and knowing it
might aid blackhat users in attacking the server.

As of CVS tip, if you are using the config-file-location-changing
features, anybody can find out the data directory location via
"show pgdata"; and they can find out where you put the secondary
config files too, if it's not default.  So we now have either a
feature or a bug.

If you consider it a feature then it's incomplete: it would be handy for
"show pgdata" to tell the truth all the time, whether you'd set the path
in postgresql.conf or not.  Ditto for the config filename variables.

If you consider it a bug then CVS tip has a potential security
vulnerability that was never there before.

I am sort of on the fence about this.  I am thinking that it would be
good to expose this information, but *only* to superusers.  It would not
take much code to add a GUC variable flag bit that prevents
non-superusers from examining the value of the GUC variable, and only a
little more code to reflect the correct paths into these variables all
the time.

Comments, objections, better ideas?  If I hear no objection I'll make it
work that way.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: DDL triggers [was Re: [GENERAL] database constraints]
Next
From: Andrew Dunstan
Date:
Subject: Re: Security implications of config-file-location patch