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

Thu, 07 Oct 2004 21:55:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Security implications of config-file-location patch


Tom Lane wrote:

>
>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.
>
>
>  
>

On the basis that I can't see that anyone but the superuser has a 
legitimate interest in the info, this sounds good.

cheers

andrew

Thu, 07 Oct 2004 22:22:14 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Security implications of config-file-location patch
Andrew Dunstan wrote:
> 
> 
> Tom Lane wrote:
> 
> >
> >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.
> >
> >
> >  
> >
> 
> On the basis that I can't see that anyone but the superuser has a 
> legitimate interest in the info, this sounds good.

If they are using tablespaces is it OK that anyone can see their
location?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 8 Oct 2004 00:21:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Security implications of config-file-location patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If they are using tablespaces is it OK that anyone can see their
> location?

Good point.  Should we obscure pg_tablespace similarly to what we do for
pg_shadow?

			regards, tom lane

Fri, 08 Oct 2004 00:28:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Security implications of config-file-location patch 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If they are using tablespaces is it OK that anyone can see their
> > location?
> 
> Good point.  Should we obscure pg_tablespace similarly to what we do for
> pg_shadow?

Well, if we feel file locations are better left only visible to
super-users, we should.  However, when managing disk space, aren't
normal users also often interested in which disk drives will store their
data?  I don't see a big value to obscuring pgdata myself.

I suppose one solution would be for administrators to name their
tablespaces after the disk drive names if they want their users will
know the drive names.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 8 Oct 2004 00:35:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Security implications of config-file-location patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Good point.  Should we obscure pg_tablespace similarly to what we do for
>> pg_shadow?

> Well, if we feel file locations are better left only visible to
> super-users, we should.  However, when managing disk space, aren't
> normal users also often interested in which disk drives will store their
> data?  I don't see a big value to obscuring pgdata myself.

My gut feeling is that it's more important to obscure pgdata than the
external tablespace locations, basically because non-default tablespaces
are likely to be on secondary disks with no particular relationship to
interesting files (such as ~postgres/.profile).  I can't back this up
with a hard argument at this late hour though ...

			regards, tom lane

Fri, 08 Oct 2004 01:38:19 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Security implications of config-file-location patch 
Tom Lane wrote:
> 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";

Btw., couldn't we come up with a more descriptive parameter name than 
"pgdata"?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Sat, 9 Oct 2004 19:07:02 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Security implications of config-file-location patch
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> 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";

> Btw., couldn't we come up with a more descriptive parameter name than 
> "pgdata"?

Sure.  Actually it was just bothering me that "-c pgdata" didn't mean
quite the same thing as setting PGDATA in the environment.  Do you like
"data_dir" or "data_directory" for the GUC variable?

			regards, tom lane

Sat, 09 Oct 2004 13:11:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Security implications of config-file-location patch 
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> 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";
> 
> > Btw., couldn't we come up with a more descriptive parameter name than 
> > "pgdata"?
> 
> Sure.  Actually it was just bothering me that "-c pgdata" didn't mean
> quite the same thing as setting PGDATA in the environment.  Do you like
> "data_dir" or "data_directory" for the GUC variable?

I was going to suggest 'data_dir' but I see 'directory' is fully spelled
out in all other GUC variables in postgresql.conf, so let's use
'data_directory'.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 9 Oct 2004 17:56:21 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Security implications of config-file-location patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I was going to suggest 'data_dir' but I see 'directory' is fully spelled
> out in all other GUC variables in postgresql.conf, so let's use
> 'data_directory'.

Done.

			regards, tom lane

Sat, 09 Oct 2004 19:13:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Security implications of config-file-location patch 