A patch to pg_regress for Windows port
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
Attachments:
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
Show quoted text
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
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
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
"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 ...
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,
Please refer
http://archives.postgresql.org/pgsql-patches/2007-01/msg00056.php
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
"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