Pedro Gimeno <pgsql-...@personal.formauri.es> wrote: > Tom Lane wrote: > >> This could be addressed by having the postmaster report its $PGDATA >> value in the pg_ping response, but I would be against that on >> security grounds. We don't let nonprivileged users know where >> PGDATA is, why would we make the information available without any >> authentication at all? > > Maybe a hash of it? I'm not really clear on why it's a security issue for someone to know the $PGDATA value, but if it is, there are some "typical" locations for which a hash could be generated and matched against the returned hash; so a hash of it would only be safe for those who chose sufficiently "creative" directory paths. On top of that, I'm not sure it's a very useful way to confirm that you've connected to the correct instance. We often get requests to replace the contents of a development or test database with a dump from a production database. More than once, the DBA doing this has forgotten to stop PostgreSQL before deleting the $PGDATA directory and creating it fresh for the restore of the PITR dump. When we attempt to start the new copy, which has the same $PGDATA, owner, and port number as the copy still running in the deleted directory, we have similar issues to those described in the original post. So, personally, I consider the data directory a less reliable test than the pid. (We don't have a lot of OS crash & reboot occurrences.) -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
