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

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

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

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

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

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?

Hmm, I can not see how a person with file access could not easily find the
file for a specific table without pg_tablespace anyway (since oid names will
be quite unique). Without file access, what malicious act is he going to do
with that info ?

I think hiding that info would not really be safer, thus not worth it.

Andreas

"Zeugswetter Andreas DAZ SD" <ZeugswetterA@spardat.at> writes:

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

Hmm, I can not see how a person with file access could not easily find the
file for a specific table without pg_tablespace anyway (since oid names will
be quite unique). Without file access, what malicious act is he going to do
with that info ?

I think hiding that info would not really be safer, thus not worth it.

Do you also feel that there's no need to hide the values of the GUC
variables pgdata etc?

regards, tom lane

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/

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

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

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