Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY

Craig Ringer <craig(at)2ndQuadrant(dot)com> writes:
> On 11/15/2012 12:46 AM, Tom Lane wrote:
>> Agreed, and there's also the question of passing switches etc to the
>> program, so the string can't be a bare file name anyway. I proposed
>> pipe symbols (|) in the string previously, but if you find that too
>> Unix-centric I suppose we could do
>>
>> COPY TABLE FROM PROGRAM 'command line';
>> COPY TABLE TO PROGRAM 'command line';

> I'd strongly prefer that from a security standpoint.

That's a reasonable concern.

> Additionally, the pipe design appears to presume the presence of a shell
> and the desirability of using it. I don't think either assumption is
> sensible.

I disagree very very strongly with that. If we prevent use of shell
syntax, we will lose a lot of functionality, for instance

copy ... from program 'foo <somefile'
copy ... from program 'foo | bar'

unless you're imagining that we will reimplement a whole lot of that
same shell syntax for ourselves. (And no, I don't care whether the
Windows syntax is exactly the same or not. The program name/path is
already likely to vary across systems, so it's pointless to suppose that
use of the feature would be 100% portable if only we lobotomized it.)

> More importantly, the shell provides fun opportunities for unexpected
> side-effects via metacharacters, leading to undesired behaviour or even
> exploits.

So? You're already handing the keys to the kingdom to anybody who can
control the contents of that command line, even if it's only to point at
the wrong program. And one man's "unexpected side-effect" is another
man's "essential feature", as in my examples above.

regards, tom lane