Re: 9.2 beta2 - pg_ctl crashes on Win32 when neither PGDATA nor -D specified

>> I note that "postgres -C data_directory" will refuse to run on the
>> command line because I've got admin privileges in Windows, and that
>> pg_ctl normally starts postgres.exe using CreateRestrictedProcess.
>> But it does not do so for the popen call in adjust_data_dir.

> if that actually is a third bug, as seems likely, somebody with access
> to a windows environment will need to deal with it.

I am able to reproduce this problem, "that pg_ctl throws error for
administrative user in the mentioned code path".

One solution to this problem is that pg_ctl invoke itself in a restricted
mode, similar to initdb.
This will allow popen call to be successful in pg_ctl code path.

Please let me know if this solution is okay, I can create the patch for it.

For Referrence initdb code is as below, we can have similar code for pg_ctl:
#ifdef WIN32

        /*
         * Before we execute another program, make sure that we are running
with a
         * restricted token. If not, re-execute ourselves with one.
         */

        if ((restrict_env = getenv("PG_RESTRICT_EXEC")) == NULL
                || strcmp(restrict_env, "1") != 0)
        {
                PROCESS_INFORMATION pi;
                char           *cmdline;

                ZeroMemory(&pi, sizeof(pi));

                cmdline = xstrdup(GetCommandLine());

                putenv("PG_RESTRICT_EXEC=1");

                if (!CreateRestrictedProcess(cmdline, &pi))
                {
                        fprintf(stderr, "Failed to re-exec with restricted
token: %lu.\n", GetLastError());
                }
                else
                {
                        /*
                         * Successfully re-execed. Now wait for child
process to capture
                         * exitcode.
                         */
                        DWORD                x;

                        CloseHandle(pi.hThread);
                        WaitForSingleObject(pi.hProcess, INFINITE);

                        if (!GetExitCodeProcess(pi.hProcess, &x))
                        {
                                fprintf(stderr, "Failed to get exit code
from subprocess: %lu\n", GetLastError());
                                exit(1);
                        }
                        exit(x);
                }
        }
#endif

-----Original Message-----
From: pgsql-bugs-owner@postgresql.org
[mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Tuesday, June 12, 2012 7:53 AM
To: Edmund Horner
Cc: pgsql-bugs@postgresql.org; Bruce Momjian
Subject: Re: [BUGS] 9.2 beta2 - pg_ctl crashes on Win32 when neither PGDATA
nor -D specified

Edmund Horner <ejrh00@gmail.com> writes:
> In 9.1, if I run "pg_ctl start" without providing way for it to find
> the datadir, it prints the error:

>     C:\ehorner\pgsql-old\bin>pg_ctl start
>     pg_ctl: no database directory specified and environment variable
> PGDATA unset
>     Try "pg_ctl --help" for more information.

> In 9.2 (beta1 and beta2), it runs for a couple of seconds and then
> Windows pops up an error box saying it has "encountered a problem".  I
> ...
> I think it could be something in
>
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=aaa6e1def2
92cdacb6b27088898793b1b879fedf#patch5

Hm, that patch seems to be several bricks shy of a load.  I will fix
two obvious bugs in it:

(1) not dump core on boxes where printf("%s", NULL) dumps core;

(2) not try to call adjust_data_dir before complaining for lack of
a -D switch; since adjust_data_dir does not do anything to the value
of pg_config, it's just silly to do things in that order.

However,

> I note that "postgres -C data_directory" will refuse to run on the
> command line because I've got admin privileges in Windows, and that
> pg_ctl normally starts postgres.exe using CreateRestrictedProcess.
> But it does not do so for the popen call in adjust_data_dir.

if that actually is a third bug, as seems likely, somebody with access
to a windows environment will need to deal with it.

            regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs