On 03.09.2012 03:23, Tom Lane wrote:
1. As you can see above, the feature is triggered by specifying the new
connection option "standalone_datadir", whose value must be the location
of the data directory.  I also invented an option "standalone_backend",
which can be set to specify which postgres executable to launch.  If the
latter isn't specified, libpq defaults to trying the installation PGBINDIR
that was selected by configure.  (I don't think it can use the relative
path tricks we use in pg_ctl and elsewhere, since there's no good reason
to assume that it's running in a Postgres-supplied program.)  I'm not
particularly wedded to these names or the syntax, but I think this is the
basic functionality we'd need.

Are there security issues with this? If a user can specify libpq connection options, he can now execute any file he wants by passing it as standalone_backend. Granted, you shouldn't allow an untrusted user to specify libpq connection options, because allowing to open a TCP connection to an arbitrary address can be a problem by itself, but it seems like this might make the situation much worse. contrib/dblink springs to mind..

3. The bulk of the changes have to do with the fact that we need to keep
track of two file descriptors not one.  This was a bit tedious, but fairly
straightforward --- though I was surprised to find that send() and recv()
don't work on pipes, at least not on Linux.  You have to use read() and
write() instead.

Would socketpair(2) be simpler?

7. I haven't tried to make pg_upgrade use this yet.

Hmm, pg_upgrade uses pg_dumpall rather than pg_dump, so it needs to connect once per database. That means launching the standalone backend multiple times. I guess that works, as long as pg_dumpall doesn't try to hold multiple connections open at any one time.

- Heikki

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to