Re: [Patch] - Fix for bug #2558, InitDB failed to run

Hi All,


As some of you already noticed and as mentioned in pgsql-hackers before,
the initDB process failed to run on some windows 2003 machines.

Although this issue was already discussed by James Hughes,Martijn,Jim Nasby and others I didn't no patch was created and
no fix was committed to the CVS.

Description:

On some windows 2003 machine there is no access to the nul device for non administrator's users.
The initDB.c redirect the output to > DEVNUL which on windows defined has "nul".

There were two options to solve this issue:

Create a new file , grant a write permission for the Postgres user and redirect the output to that file. (EnterpriseDB use this method)
Canceling the redirection at all.

I choose the second option and omit the redirection in any case that it windows machine and the redirection was sent to DEVNULL.

The only files that I changed are: initDB.c, exec.c and pg_ctl.c


I think postgres must solve this issue, as more and more windows 2003 machine will be discovered with this limitation which prevent from the users to install (actually to initialize ) the DB.

One more comment:
As today we have and MSI installer which redirect the initDB output to a log file by default (and we can also run it in the background) there is no point to use redirection at all.

The fixed files are attached.

Regards
Dror Bar-Gil



_________________________________________________________________
Try Live.com: where your online world comes together - with news, sports, weather, and much more.
http://www.live.com/getstarted

dror wrote:

> There were two options to solve this issue:
>
> Create a new file , grant a write permission for the Postgres user
> and redirect the output to that file. (EnterpriseDB use this method)
> Canceling the redirection at all.
>
> I choose the second option and omit the redirection in any case that
> it windows machine and the redirection was sent to DEVNULL.
>
> The only files that I changed are: initDB.c, exec.c and pg_ctl.c

Please submit the changes as patches, instead of the whole files. Also,
please specify which branch do these patches apply -- is this for 8.1,
or for the current development code? When checked against the 8.1
pg_ctl.c, the file you sent only contains a regression for a bug fix,
and no change related to what you describe above.

On the other hand, it may be useful to lose the redirection only on the
cases where it fails, so we still have reasonable behavior on non-broken
platforms. Or maybe there's a better solution.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> dror wrote:
>
>
>> There were two options to solve this issue:
>>
>> Create a new file , grant a write permission for the Postgres user
>> and redirect the output to that file. (EnterpriseDB use this method)
>> Canceling the redirection at all.
>>
>> I choose the second option and omit the redirection in any case that
>> it windows machine and the redirection was sent to DEVNULL.
>>
>> The only files that I changed are: initDB.c, exec.c and pg_ctl.c
>>
>
> Please submit the changes as patches, instead of the whole files. Also,
> please specify which branch do these patches apply -- is this for 8.1,
> or for the current development code? When checked against the 8.1
> pg_ctl.c, the file you sent only contains a regression for a bug fix,
> and no change related to what you describe above.
>
> On the other hand, it may be useful to lose the redirection only on the
> cases where it fails, so we still have reasonable behavior on non-broken
> platforms. Or maybe there's a better solution.
>
>

I am inclined to say we should make it into a runtime test and use a
tmpfile on Windows if the test fails. I am more than somewhat perplexed
as to why the NUL device should be a security risk ... what are they
thinking??

The case that bothers me more is where input is redirected - will that
also work?

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I am more than somewhat perplexed as to why the NUL device should be a
> security risk ... what are they thinking??

Frankly, I don't believe it; even Microsoft can't be that stupid.
And I can't find any suggestion that they've done this in a google
search. I think the OP is misdiagnosing his problem.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> I am more than somewhat perplexed as to why the NUL device should be a
>> security risk ... what are they thinking??
>>
>
> Frankly, I don't believe it; even Microsoft can't be that stupid.
> And I can't find any suggestion that they've done this in a google
> search. I think the OP is misdiagnosing his problem.
>
An older message suggests that a service pack induced this problem, per
MS. I just tried it as non-admin on a W2K3 machine with recent hotfixes,
and the command "dir >nul" _did_ work for me.
Though neglected, it still sounds like a virus scanner issue to me.

Regards,
Andreas

Andreas Pflug wrote:
> Tom Lane wrote:
> > Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >
> >> I am more than somewhat perplexed as to why the NUL device should be a
> >> security risk ... what are they thinking??
> >>
> >
> > Frankly, I don't believe it; even Microsoft can't be that stupid.
> > And I can't find any suggestion that they've done this in a google
> > search. I think the OP is misdiagnosing his problem.
> >
> An older message suggests that a service pack induced this problem, per
> MS. I just tried it as non-admin on a W2K3 machine with recent hotfixes,
> and the command "dir >nul" _did_ work for me.
> Though neglected, it still sounds like a virus scanner issue to me.

Yes, it seems we will need more information on this. We need someone at
a win32 command prompt to show us a "> nul" failure.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Andreas Pflug wrote:
>> Tom Lane wrote:
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>
>>>> I am more than somewhat perplexed as to why the NUL device should be a
>>>> security risk ... what are they thinking??
>>>>
>>> Frankly, I don't believe it; even Microsoft can't be that stupid.
>>> And I can't find any suggestion that they've done this in a google
>>> search. I think the OP is misdiagnosing his problem.
>>>
>> An older message suggests that a service pack induced this problem, per
>> MS. I just tried it as non-admin on a W2K3 machine with recent hotfixes,
>> and the command "dir >nul" _did_ work for me.
>> Though neglected, it still sounds like a virus scanner issue to me.
>
> Yes, it seems we will need more information on this. We need someone at
> a win32 command prompt to show us a "> nul" failure.

OTOH,
what issues might arise if the output is redirected to a legal tmp file?

Regards,
Andreas

Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Andreas Pflug wrote:
> >> Tom Lane wrote:
> >>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >>>
> >>>> I am more than somewhat perplexed as to why the NUL device should be a
> >>>> security risk ... what are they thinking??
> >>>>
> >>> Frankly, I don't believe it; even Microsoft can't be that stupid.
> >>> And I can't find any suggestion that they've done this in a google
> >>> search. I think the OP is misdiagnosing his problem.
> >>>
> >> An older message suggests that a service pack induced this problem, per
> >> MS. I just tried it as non-admin on a W2K3 machine with recent hotfixes,
> >> and the command "dir >nul" _did_ work for me.
> >> Though neglected, it still sounds like a virus scanner issue to me.
> >
> > Yes, it seems we will need more information on this. We need someone at
> > a win32 command prompt to show us a "> nul" failure.
>
> OTOH,
> what issues might arise if the output is redirected to a legal tmp file?

No idea, but we aren't going to change the code without more facts. We
don't have the resources to be making code changes without concrete
information.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> what issues might arise if the output is redirected to a legal tmp file?

Well, (1) finding a place to put the temp file, ie a writable directory;
(2) ensuring the file is removed afterwards; (3) not exposing the user
to security hazards due to unsafe use of a temp file (ye olde
overwrite-a-symlink risk). Perhaps a few more I didn't think of.

It's not a trivial change, and the evidence presented so far hasn't
convinced me that we need to put in the effort.

regards, tom lane

Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>
>> what issues might arise if the output is redirected to a legal tmp file?
>>
>
> Well, (1) finding a place to put the temp file, ie a writable directory;
> (2) ensuring the file is removed afterwards; (3) not exposing the user
> to security hazards due to unsafe use of a temp file (ye olde
> overwrite-a-symlink risk). Perhaps a few more I didn't think of.
>

AFAICS all DEVNULL usages result from redirecting postmaster's output,
which usually goes to $DATADIR/serverlog at runtime. If this would be
used here too, (1) is as safe as any $DATADIR, (2) is as safe as
cleaning up after failure usually is, (3) can't happen because the
directory is checked to be empty before initdb anyway. Additionally,
there's might be cases when a meaningful logfile from initdb is
desirable too. So why no redirection to initlog or so?

Regards,
Andreas