Re: [HACKERS] 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/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Security implications of config-file-location patch
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? 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Security implications of config-file-location patch
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 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Security implications of config-file-location patch
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)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Security implications of config-file-location patch
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Security implications of config-file-location patch
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 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Security implications of config-file-location patch
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)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Security implications of config-file-location patch
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 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Security implications of config-file-location patch
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 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
