SEO

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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
>

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 ...

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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...1/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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly