Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"
Date: 2013-11-25 13:37:17
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDAD798@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24 November 2013, Tom Lane Wrote:
> > One suggestion:
> > Instead of using sizeof(cmdLine),
> > a. Can't we use strlen (hence small 'for' loop).
> > b. Or use memmove to move one byte.
>
> I looked at this patch a bit. I agree that we need to fix
> pgwin32_CommandLine to double-quote the executable name, but it needs a
> great deal more work than that :-(. Whoever wrote this code was
> apparently unacquainted with the concept of buffer overrun. It's not
> going to be hard at all to crash pg_ctl with overlength arguments. I'm
> not sure that that amounts to a security bug, but it's certainly bad.
>
> After some thought it seems like the most future-proof fix is to not
> use a fixed-length buffer for the command string at all. The attached
> revised patch switches it over to using a PQExpBuffer instead, which is
> pretty much free since we're relying on libpq anyway in this program.
> (We still use a fixed-length buffer for the program path, which is OK
> because that's what find_my_exec and find_other_exec expect.)
>
> In addition, I fixed it to append .exe in both cases not just the one.
>
> I'm not in a position to actually test this, but it does compile
> without warnings.

I tested the latest patch. My observation is:
If we give relative data directory path while registering the service, then service start fails.
But same works if the data directory is absolute path.

Looks like an existing issue. May be we need to internally convert relative data path to absolute.

Thanks and Regards,
Kumar Rajeev Rastogi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-11-25 14:00:22 Re: new unicode table border styles for psql
Previous Message Bruce Momjian 2013-11-25 13:35:13 Re: [GENERAL] pg_upgrade ?deficiency