Re: BUG #16080: pg_ctl is failed if a fake cmd.exe exist in the current directory.

On Sun, Oct 27, 2019 at 4:42 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <
> juanjo(dot)santamaria(at)gmail(dot)com> writes:
> > On Sat, Oct 26, 2019 at 7:44 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Hm. I don't have any objection to using COMSPEC if it's set, but
> >> of course that changes nothing from a security perspective. It's
> >> just a different route by which pg_ctl, pg_upgrade, etc can be
> >> misled.
>
> > Please find attached a patch with this simple modification.
>
> I poked around a bit for other references to cmd.exe. It looks
> like psql's do_shell() is handling this correctly already, but should
> we not also fix spawn_process() in src/test/regress/pg_regress.c ?
>
>
Agreed, so please find attached an updated patch.

> There are also a couple of references in pg_upgrade's test.sh,
> but I don't feel a need to change those.
>
>
Agreed, this will honor PATH since is called from a shell,

> Another point that could be raised here: seeing that psql honors the
> SHELL variable to substitute for /bin/sh, should these other programs
> do likewise? I'm inclined to think not, because what psql is doing is
> launching an interactive shell, so the user's shell preference should be
> honored. In these other cases we want plain old Bourne shell thank you,
> so ignoring SHELL seems correct. But it's worth thinking about, and
> perhaps adding a comment about.
>
>
Also agree on this: honoring SHELL makes sense only if there is client
interaction.

Regards,

Juan José Santamaría Flecha