Thread: Re: [PATCHES] [Patch] - Fix for bug #2558, InitDB failed to run
Andrew Dunstan <andrew@dunslane.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@dunslane.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@dunslane.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@momjian.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@dunslane.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@dunslane.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@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Andreas Pflug <pgadmin@pse-consulting.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@pse-consulting.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