Re: [HACKERS] Security implications of config-file-location patch

2004-10-09 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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 ---(end of broadcast)

Re: [HACKERS] Security implications of config-file-location patch

2004-10-09 Thread Bruce Momjian
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> 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

Re: [HACKERS] Security implications of config-file-location patch

2004-10-09 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> 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

Re: [HACKERS] Security implications of config-file-location patch

2004-10-09 Thread Peter Eisentraut
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.o

Re: [HACKERS] Security implications of config-file-location patch

2004-10-08 Thread Tom Lane
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> 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 name

Re: [HACKERS] Security implications of config-file-location patch

2004-10-08 Thread Zeugswetter Andreas DAZ SD
> > 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_tablespac

Re: [HACKERS] Security implications of config-file-location patch

2004-10-07 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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 inter

Re: [HACKERS] Security implications of config-file-location patch

2004-10-07 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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

Re: [HACKERS] Security implications of config-file-location patch

2004-10-07 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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 ---(end of broadcast)

Re: [HACKERS] Security implications of config-file-location patch

2004-10-07 Thread Bruce Momjian
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 t

Re: [HACKERS] Security implications of config-file-location patch

2004-10-07 Thread Andrew Dunstan
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