Re: Re: fixing pg_ctl with relative paths - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: Re: fixing pg_ctl with relative paths
Date
Msg-id 5F260E2A.7010701@anastigmatix.net
Whole thread Raw
In response to Re: fixing pg_ctl with relative paths  (Josh Kupershmidt <schmiddy@gmail.com>)
List pgsql-hackers
On 07/01/13 20:10, Josh Kupershmidt wrote:
> I am eager to see the relative paths issue fixed, but maybe we need to
> bite the bullet and sort out the escaping of command-line options in
> the rest of pg_ctl first, so that a DataDir like "/tmp/here's a \"
> quote" can consistently be used by pg_ctl {start|stop|restart} before
> we can fix this wart.

It was timely to see this thread recently revived, as I had only just
recently needed to contend with the same escaping issue while writing a
PostgresNode-like test harness for PL/Java, where I discovered I have
to pass -o values pre-transformed to pg_ctl, and even have to do that
platform-sensitively, to pre-transform them according to the rules for
Bourne shell or those for cmd.exe.

I looked at the history of that code in pg_ctl and saw that it went
all the way back, so I assumed that any proposal to fix it would probably
be met with "it has always been that way and anybody calling it with
arbitrary arguments must be pre-transforming them anyway and it would be
bad to break that." (And anyway, my test harness thing is now yet one more
thing that depends on the current behavior.)

But would it be worthwhile to perhaps make a start, add an option
(non-default at first) that changes to an implementation that passes
values transparently and isn't injection-prone?

(I use "injection-prone" not because I'd be especially concerned about
command injection by anybody who can already run pg_ctl, just because
it's an economical way to describe what pg_ctl currently does.)

Regards,
-Chap



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Comment simplehash/dynahash trade-offs
Next
From: David Rowley
Date:
Subject: Re: Comment simplehash/dynahash trade-offs