On Fri, Oct 16, 2009 at 10:33 AM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > 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.)
Well, then Tom's idea of using a random number seems pretty solid no matter how you slice it. Maybe a UUID. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
