Thread: A patch to pg_regress for Windows port

A patch to pg_regress for Windows port

From
"Gurjeet Singh"
Date:
On Windows, if logged in as an Administrator, 'make check' fails with our standard error, saying:

<quote>
Execution of PostgreSQL by a user with administrative permissions is not
permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromises.  See the documentation for
more information on how to properly start the server.
</quote>

But, for some time now, a Windows' Administrator *can* run a postgres without having to create a normal user; he just has to use pg_ctl to do so. Thanks to code written by Magnus, pg_ctl gives up it's administrative privilges before starting the postmaster, and hence the postmaster runs without critical privileges.

So I thought that 'make check' could also make use of that functionality, and hence this patch.

Is this new pg_ctl behavior mentioned anywhere in the docs?

Best regards,

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
Attachment

Re: A patch to pg_regress for Windows port

From
"Gurjeet Singh"
Date:
This patch removes double-quotes from around the listen_addresses=%s part; I couldn't find a way of doing that. But then, the questions is, can the %s (hostname) have spaces embedded in it?

--
gurjeet[.singh]@ EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com

On 1/6/07, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
On Windows, if logged in as an Administrator, 'make check' fails with our standard error, saying:

<quote>
Execution of PostgreSQL by a user with administrative permissions is not
permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromises.  See the documentation for
more information on how to properly start the server.
</quote>

But, for some time now, a Windows' Administrator *can* run a postgres without having to create a normal user; he just has to use pg_ctl to do so. Thanks to code written by Magnus, pg_ctl gives up it's administrative privilges before starting the postmaster, and hence the postmaster runs without critical privileges.

So I thought that 'make check' could also make use of that functionality, and hence this patch.

Is this new pg_ctl behavior mentioned anywhere in the docs?

Best regards,

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com

Re: A patch to pg_regress for Windows port

From
Magnus Hagander
Date:
Gurjeet Singh wrote:
> On Windows, if logged in as an Administrator, 'make check' fails with
> our standard error, saying:
>
> <quote>
> Execution of PostgreSQL by a user with administrative permissions is not
> permitted.
> The server must be started under an unprivileged user ID to prevent
> possible system security compromises.  See the documentation for
> more information on how to properly start the server.
> </quote>
>
> But, for some time now, a Windows' Administrator *can* run a postgres
> without having to create a normal user; he just has to use pg_ctl to do
> so. Thanks to code written by Magnus, pg_ctl gives up it's
> administrative privilges before starting the postmaster, and hence the
> postmaster runs without critical privileges.
>
> So I thought that 'make check' could also make use of that
> functionality, and hence this patch.

Per previous discussion with Tom (in the archives, but I can't get there
right now), this is the wrong way to do it. We lose the ability to kill
the postmaster if it fails.

I have a proper working solution in my tree that I will submit soon
along with the changes required to make pg_regress work in a non-msys
environment using MSVC.

//Magnus


Re: A patch to pg_regress for Windows port

From
"Gurjeet Singh"
Date:
cool...

On 1/6/07, Magnus Hagander <magnus@hagander.net> wrote:
Gurjeet Singh wrote:
> On Windows, if logged in as an Administrator, 'make check' fails with
> our standard error, saying:
>
> <quote>
> Execution of PostgreSQL by a user with administrative permissions is not
> permitted.
> The server must be started under an unprivileged user ID to prevent
> possible system security compromises.  See the documentation for
> more information on how to properly start the server.
> </quote>
>
> But, for some time now, a Windows' Administrator *can* run a postgres
> without having to create a normal user; he just has to use pg_ctl to do
> so. Thanks to code written by Magnus, pg_ctl gives up it's
> administrative privilges before starting the postmaster, and hence the
> postmaster runs without critical privileges.
>
> So I thought that 'make check' could also make use of that
> functionality, and hence this patch.

Per previous discussion with Tom (in the archives, but I can't get there
right now), this is the wrong way to do it. We lose the ability to kill
the postmaster if it fails.

I have a proper working solution in my tree that I will submit soon
along with the changes required to make pg_regress work in a non-msys
environment using MSVC.

//Magnus




--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet @{ gmail | hotmail | yahoo }.com

Re: A patch to pg_regress for Windows port

From
Tom Lane
Date:
"Gurjeet Singh" <singh.gurjeet@gmail.com> writes:
> This patch removes double-quotes from around the listen_addresses=%s part; I
> couldn't find a way of doing that. But then, the questions is, can the %s
> (hostname) have spaces embedded in it?

Yes, because it can be more than one hostname.  Why do you want to
remove the quotes?

            regards, tom lane

PS: there wasn't any patch attached, but I doubt we'd have accepted it
anyway ...

Re: A patch to pg_regress for Windows port

From
"Gurjeet Singh"
Date:


On 1/6/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Gurjeet Singh" <singh.gurjeet@gmail.com> writes:
> This patch removes double-quotes from around the listen_addresses=%s part; I
> couldn't find a way of doing that. But then, the questions is, can the %s
> (hostname) have spaces embedded in it?

Yes, because it can be more than one hostname.

But the code in postmaster.c expects the list to be comma separated.

        if (!SplitIdentifierString(rawstring, ',', &elemlist))
        {
            /* syntax error in list */
            ereport(FATAL,
                    (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                     errmsg("invalid list syntax for \"listen_addresses\"")));
        }

  Why do you want to
remove the quotes?
 
No, I didn't want to, but I was getting "FATAL:  the database system is starting up" in the log if I surrounded that var=val with double-quotes. Later I remedied that by attaching a -w option to the pg_ctl command.

 PS: there wasn't any patch attached,

but I doubt we'd have accepted it
anyway ...

Any particular reason?

A few minutes after the submission, after I read more code, I wouldn't have either! I noticed (and Magnus also pointed it out) that we use the returned PID to kill the postmaster if it doesn't respond. There's no easy way of doing that if we use pg_ctl to start the postmaster! Let's wait for Magnus' patch to make pg_regress independent of MinGW.

Best regards,

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com

Re: A patch to pg_regress for Windows port

From
Tom Lane
Date:
"Gurjeet Singh" <singh.gurjeet@gmail.com> writes:
> On 1/6/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yes, because it can be more than one hostname.

> But the code in postmaster.c expects the list to be comma separated.

Sure, but SplitIdentifierString allows for whitespace, eg

    'host1, host2, host3'

            regards, tom lane