Thread: Security implications of config-file-location patch
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
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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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