From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heath Lord <heath.lord@crunchydata.com>
cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
 pgsql-bugs@lists.postgresql.org,
        Alexander Lakhin <exclusion@gmail.com>
Subject: Re: BUG #16259: Cannot Use "pg_ctl start -l logfile" on Clean Install
 on Windows Server 2012/2016
In-reply-to: 
 <CA+BEBhtnsHSAUO_BE595R3NWSsYWcg1Gk9yv5+eYqRd-AtUi9Q@mail.gmail.com>
References: <16259-c5ebed32a262a8b1@postgresql.org>
 <22619.1581702327@sss.pgh.pa.us>
 <98b2f7d0-9010-358a-36c9-a5b09020dd08@postgresql.org>
 <CA+BEBhumRTNnNp0xcvu0W9nwjiK2Dt5rZmovf3PoHJ+iHf1FaA@mail.gmail.com>
 <3568.1581710233@sss.pgh.pa.us>
 <CA+BEBhtnsHSAUO_BE595R3NWSsYWcg1Gk9yv5+eYqRd-AtUi9Q@mail.gmail.com>
Comments: In-reply-to Heath Lord <heath.lord@crunchydata.com>
	message dated "Fri, 14 Feb 2020 16:22:40 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7958.1581716776.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 14 Feb 2020 16:46:16 -0500
Message-ID: <7959.1581716776@sss.pgh.pa.us>
Precedence: bulk

Heath Lord <heath.lord@crunchydata.com> writes:
>    Another interesting thing that we have found is that this issue
> only manifests
> itself if you are trying to launch the pg_ctl command as a privileged
> user.  If you
> try to run this command as a user who is not an Administrator, then we d=
o not
> see this issue.  This is another reason why Dory does not exhibit this b=
ehavior.
>   With this finding, it has to be something with how pg_ctl is restricti=
ng the
> user when running the postgres.exe command from the CMD.exe process,
> so we are not trying to launch postgres as a privileged user.

OOOHHH ... I think the light just went on, then.  The reason we have
an issue is that we drop admin privileges (via CreateRestrictedProcess)
when we launch CMD.EXE, just below this.  So we are still admin when
the new code touches the log file, and that's why it's getting created
with different privileges from files that the postmaster (or CMD.EXE)
would create.

The idea I'd had for a fix is that we don't need to actually create the
file if it's not there yet.  All we need is to delay if it's there and
can't be opened.  So rather than open for writing, I think we could open
for reading, along the lines of

        FILE       *fd =3D fopen(log_file, "r");

        if (fd !=3D NULL)     /* we may just ignore any error */
            fclose(fd);

The looping logic in pgwin32_open doesn't really care which kind
of access we're asking for.

BTW, we could make this at least slightly cheaper by using
open() not fopen().

Alexander, this was your patch to start with ... any thoughts?

			regards, tom lane