Thread: Bug with initDB under windows 2003

Bug with initDB under windows 2003

From
"dror bar"
Date:
Hi All,
 
On some windows 2003 machines the initDB process failed with the following error:
 
Running in debug mode.
The files belonging to this database system will be owned by user "V_MYUSER".
This user must also own the server process.
 
The database cluster will be initialized with locale English_United States.1252.
 
fixing permissions on existing directory E:/Postgres\Data ... ok
creating directory E:/Postgres\Data/global ... ok
creating directory E:/Postgres\Data/pg_xlog ... ok
creating directory E:/Postgres\Data/pg_xlog/archive_status ... ok
creating directory E:/Postgres\Data/pg_clog ... ok
creating directory E:/Postgres\Data/pg_subtrans ... ok
creating directory E:/Postgres\Data/pg_twophase ... ok
creating directory E:/Postgres\Data/pg_multixact/members ... ok
creating directory E:/Postgres\Data/pg_multixact/offsets ... ok
creating directory E:/Postgres\Data/base ... ok
creating directory E:/Postgres\Data/base/1 ... ok
creating directory E:/Postgres\Data/pg_tblspc ... ok
selecting default max_connections ... Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
10
selecting default shared_buffers ... Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
Access is denied.
50
creating configuration files ... ok
creating template1 database in E:/Postgres\Data/base/1 ... VERSION=8.1.4
PGDATA=E:/Postgres\Data
share_path=E:/Program Files/postgres/Database/share
PGPATH=E:/Program Files/postgres/Database/bin
POSTGRES_SUPERUSERNAME=V_MYUSER
POSTGRES_BKI=E:/Program Files/postgres/Database/share/postgres.bki
POSTGRES_DESCR=E:/Program Files/postgres/Database/share/postgres.description
 

The EnterpriseDB database which is based on postgress works fine.

After short investigation, I found that this is not the first case this behavior was seen.

It seems that the bug is some how connected to access permission  for the 'nul' device.
The initDB.c trying to run something like:
postgres.exe -boot -x0 -F -c shared_buffers=200 -c max_connections=40 template1 <"/nul"
After looking at EnterpiseDB and some other help I think the PostgreSQL source need to be  modified and re-direct the output from postgres.exe to a file and grants access (to the file) to the postgres service user.
 
 I am willing to contribute and do this fix and appreciate comments from others who already familiar with this issue.
 
Regards
Dror


With MSN Spaces email straight to your blog. Upload jokes, photos and more. It's free! It's free!

Re: Bug with initDB under windows 2003

From
Martijn van Oosterhout
Date:
On Wed, Aug 02, 2006 at 09:55:53AM +0000, dror bar wrote:
> Hi All,
>
> On some windows 2003 machines the initDB process failed with the following error:

This came up before. It seems microsoft decided to restrict access to
the NUL device in a recent security update.

http://archives.postgresql.org/pgsql-hackers/2006-03/msg01262.php

Unfortunatly that thread didn't come to a resolution. Does anyone have
more info on this?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Re: Bug with initDB under windows 2003

From
"dror"
Date:
<div align="left" dir="ltr"><font color="#000000" face="Arial" size="2">Hi James,</font></div><div align="left"
dir="ltr"><fontface="Arial" size="2"></font> </div><div align="left" dir="ltr"><font face="Arial" size="2">I just
wantedto inform you all that I solve the issue, it was indeed the nul device as James and <font>Martijn</font>
mention.</font></div><divalign="left" dir="ltr"><font face="Arial" size="2">I have change the source to redirect the
outputto a log file, to which I gave permission to the "postgres" user.</font></div><div align="left" dir="ltr"><font
face="Arial"size="2">The file (currently) is created at the temp folder.</font></div><div align="left" dir="ltr"><font
face="Arial"size="2">This is critical bug due to the fact that on more and more win2003 machines the postgres
installationfailed to initialize the DB.</font></div><div align="left" dir="ltr"><font face="Arial"
size="2"></font> </div><divalign="left" dir="ltr"><font face="Arial" size="2">In any case, I am about to push this fix
tobe part of the formal postgres source.<br />Is anyone know ,who should I write to in order to test and checked this
fixto the CSV.</font></div><div align="left" dir="ltr"><font face="Arial">Regards</font></div><div align="left"
dir="ltr"><fontface="Arial">Dror</font></div><br /><hr />Express yourself instantly with Windows Live Messenger! <a
href="http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=joinmsncom/messenger"
target="_new">WindowsLive Messenger!</a> 

Re: Bug with initDB under windows 2003

From
Martijn van Oosterhout
Date:
On Thu, Aug 03, 2006 at 06:49:31PM +0000, dror wrote:
> Hi James,
>
> I just wanted to inform you all that I solve the issue, it was indeed the nul device as James and Martijn mention.
> I have change the source to redirect the output to a log file, to which I gave permission to the "postgres" user.
> The file (currently) is created at the temp folder.
> This is critical bug due to the fact that on more and more win2003 machines the postgres installation failed to
initializethe DB. 

To be honest, this is the kind of crap that bugs me about Windows. It
happens all the time that you want to dump the output of a program to
nowhere. And then they make it so only admins can use it? Writing it to
a file is a hack, you don't want the output, that why you send it to
the NUL device.

Have you been able to determine *why* Microsoft made this braindead
decision? Or where it's documented? Their own knowledgebase is filled
with examples of using the device, so I imagine they'll have to post a
workaround somewhere...

> In any case, I am about to push this fix to be part of the formal postgres source.Is anyone know ,who should I write
toin order to test and checked this fix to the CSV. 

Submit a patch to the patches list, where it will be reveiwed by the
relevenet people.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Re: Bug with initDB under windows 2003

From
"Magnus Hagander"
Date:
> > Hi James,
> >
> > I just wanted to inform you all that I solve the issue, it was
> indeed the nul device as James and Martijn mention.
> > I have change the source to redirect the output to a log file, to
> which I gave permission to the "postgres" user.
> > The file (currently) is created at the temp folder.
> > This is critical bug due to the fact that on more and more
> win2003 machines the postgres installation failed to initialize the
> DB.
>
> To be honest, this is the kind of crap that bugs me about Windows.
> It happens all the time that you want to dump the output of a
> program to nowhere. And then they make it so only admins can use
> it? Writing it to a file is a hack, you don't want the output, that
> why you send it to the NUL device.
>
> Have you been able to determine *why* Microsoft made this braindead
> decision? Or where it's documented? Their own knowledgebase is
> filled with examples of using the device, so I imagine they'll have
> to post a workaround somewhere...

AFAIK, nobody has posted any links to information that shows that
Microsoft actually *did* change this. I've searched their KB some
(including the partner-only one for people with the paid agreements,
which contains information about bugs that they don't want to be
public), and find nothing about it.

Unless you can reproduce this on a clean system, I'm definitely inclined
to say this is caused by some other piece of software on the machine -
firewall, antivirus, antispyware or virus/spyware itself.

(To reiterate a point from many other discussions, when it comes to AV,
FW, AS software, it's very often not enough to disable it. And there are
cases when even an uninstall isn't enough, because the vendor believe
they have the right to stick around and tell you now and then to get
their new version etc.)

//Magnus



Re: Bug with initDB under windows 2003

From
"Magnus Hagander"
Date:
> > Have you been able to determine *why* Microsoft made this
> braindead
> > decision? Or where it's documented? Their own knowledgebase is
> filled
> > with examples of using the device, so I imagine they'll have to
> post a
> > workaround somewhere...
>
> AFAIK, nobody has posted any links to information that shows that
> Microsoft actually *did* change this. I've searched their KB some
> (including the partner-only one for people with the paid
> agreements, which contains information about bugs that they don't
> want to be public), and find nothing about it.
>
> Unless you can reproduce this on a clean system, I'm definitely
> inclined to say this is caused by some other piece of software on
> the machine - firewall, antivirus, antispyware or virus/spyware
> itself.

Actually, I've been able to find some more information about this, which
confirms that the problem is access rights on the NUL device, but it's
*NOT* set by a MS security patch.

I'd be interested in seeing the output from the command:
Subinacl /service NULL

On a system where this does not work.

(If you get an empty update, make sure you have a version of subinacl
that corresponds to your windows version)

(There are known apps that mess this up, but my NDA prevents me from
telling you which one(s)...)

//Magnus



Re: Bug with initDB under windows 2003

From
"dror"
Date:
Hi Magnus,<br />  <br /> Magnus Wrote:<br /> > I'd be interested in seeing the output from the command:<br />>
Subinacl /service NULL<br/>> <br />> On a system where this does not work.<br />> <br />  <br /> Here is the
outputfor "Subinacl /service NULL"<br /> Both, for the Administrator user and for the Postgres user:<br />  <br />
Postgresuser:<br /> >Subinacl /service NULL<br />SeSecurityPrivilege : Access is denied.<br /> WARNING :Unable to
setSeSecurityPrivilege privilege. This privilege may be required.<br />Error OpenSCManager : Access is denied.<br /><br
/>ElapsedTime: 00 00:00:00<br />Done:        0, Modified        0, Failed        0, Syntax errors        0<br /><br />
----------------------------------------------------------------------------------<br/> Administrator user:<br />  <br
/>==============<br />+Service NULL<br />==============<br />/control=0x0<br />/owner             =system<br />/primary
group    =system<br />/audit ace count   =1<br />/aace =everyone         SYSTEM_AUDIT_ACE_TYPE-0x2<br />       
FAILED_ACCESS_ACE_FLAG-<font>0x80</font>   FAILED_ACCESS_ACE_FLAG-0x0x80<br />        SERVICE_ALL_ACCESS<br />/perm.
acecount   =6<br />/pace =system   ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />       
SERVICE_QUERY_CONFIG-0x1          SERVICE_QUERY_STATUS-0x4           SERVICE_ENUMERATE_DEPEND-0x8<br />       
SERVICE_START-0x10                SERVICE_STOP-0x20                  SERVICE_PAUSE_CONTINUE-0x40<br
/>_INTERROGATE-0x80<br/>        READ_CONTROL-0x20000               SERVICE_USER_DEFINED_CONTROL-0x0100<br />/pace
=builtin\administrators  ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />        SERVICE_ALL_ACCESS<br />/pace
=interactive     ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />        SERVICE_QUERY_CONFIG-0x1          
SERVICE_QUERY_STATUS-0x4          SERVICE_ENUMERATE_DEPEND-0x8<br />       
SERVICE_INTERROGATE-<font>0x80</font>          READ_CONTROL-0x20000              
SERVICE_USER_DEFINED_CONTROL-0x0100<br/>/pace =service  ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />       
SERVICE_QUERY_CONFIG-0x1          SERVICE_QUERY_STATUS-0x4           SERVICE_ENUMERATE_DEPEND-0x8<br />       
SERVICE_INTERROGATE-<font>0x80</font>          READ_CONTROL-0x20000              
SERVICE_USER_DEFINED_CONTROL-0x0100<br/>/pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br
/>       SERVICE_USER_DEFINED_CONTROL-0x0100<br />/pace =builtin\power users     
ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br/>        SERVICE_QUERY_CONFIG-0x1          
SERVICE_QUERY_STATUS-0x4          SERVICE_ENUMERATE_DEPEND-0x8<br />        SERVICE_START-0x10                
SERVICE_STOP-0x20                 SERVICE_PAUSE_CONTINUE-0x40<br />_INTERROGATE-0x80<br />       
READ_CONTROL-0x20000              SERVICE_USER_DEFINED_CONTROL-0x0100<br /><br />Elapsed Time: 00 00:00:00<br
/>Done:       1, Modified        0, Failed        0, Syntax errors        0<br />Last Done  : NULL<br />
----------------------------------------------------------------------------------------------------<br/>  <br /> As
youcan see it failed to set SeSecurityPrivilege privilege for the Postgres user.<br /> Regards<br /> Dror;<br /><br
/><br/><br /><br /><br /><br /><hr id="stopSpelling" /><br /> > Subject: Re: [HACKERS] Bug with initDB under windows
2003<br/>> Date: Fri, 18 Aug 2006 14:33:58 +0200<br />> From: mha@sollentuna.net<br />> To:
mha@sollentuna.net;kleptog@svana.org; dror_b@hotmail.com<br />> CC: pgsql-hackers@postgresql.org<br />> <br
/>>> > Have you been able to determine *why* Microsoft made this<br />> > braindead<br />>
> > decision? Or where it's documented? Their own knowledgebase is<br/>> > filled<br />>
> > with examples of using the device, so I imagine they'll have to<br/>> > post a<br />>
> > workaround somewhere...<br/>> > <br />>
> AFAIK, nobody has posted any links to information that shows that<br/>>
> Microsoft actually *did* change this. I've searched their KB some<br/>>
> (including the partner-only one for people with the paid<br/>>
> agreements, which contains information about bugs that they don't<br/>>
> want to be public), and find nothing about it.<br/>> > <br />>
> Unless you can reproduce this on a clean system, I'm definitely<br/>>
> inclined to say this is caused by some other piece of software on<br/>>
> the machine - firewall, antivirus, antispyware or virus/spyware<br/>> > itself.<br />> <br />>
Actually, I've been able to find some more information about this, which<br/>>
confirms that the problem is access rights on the NUL device, but it's<br/>> *NOT* set by a MS security patch.<br
/>><br />> I'd be interested in seeing the output from the command:<br />> Subinacl /service NULL<br />>
<br/>> On a system where this does not work.<br />> <br />>
(If you get an empty update, make sure you have a version of subinacl<br/>>
that corresponds to your windows version)<br/>> <br />>
(There are known apps that mess this up, but my NDA prevents me from<br/>> telling you which one(s)...)<br />>
<br/>> //Magnus<br />> <br />> <br />>
---------------------------(end of broadcast)---------------------------<br/>>
TIP 4: Have you searched our list archives?<br/>> <br />>                http://archives.postgresql.org<br /><br
/><br/><hr />Be one of the first to try Windows Live Mail. <a
href="http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d"target="_new">Windows Live
Mail.</a>

Re: Bug with initDB under windows 2003

From
"Magnus Hagander"
Date:
> > I'd be interested in seeing the output from the command:
> > Subinacl /service NULL
> >
> > On a system where this does not work.
> >
>
> Here is the output for "Subinacl /service NULL"
> Both, for the Administrator user and for the Postgres user:

Thanks.


> Postgres user:
> >Subinacl /service NULL
> SeSecurityPrivilege : Access is denied.
> WARNING :Unable to set SeSecurityPrivilege privilege. This
> privilege may be required.
> Error OpenSCManager : Access is denied.

That's quite normal - the postgres user doesn't have permission to open
the SC Manager to view the permissions, because it's not a Power User.


> Administrator user:

This is good. It shows one very clear difference from what I have on a
working system, which is:

> /pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0
>         SERVICE_USER_DEFINED_CONTROL-0x0100

On my system, I have:
/pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0       SERVICE_QUERY_CONFIG-0x1
SERVICE_QUERY_STATUS-0x4
       SERVICE_ENUMERATE_DEPEND-0x8       SERVICE_INTERROGATE-0x80           READ_CONTROL-0x20000
       SERVICE_USER_DEFINED_CONTROL-0x0100



So this is the problem. Now to figure out how to fix it :-) From what I
can tell it simply needs to add back the missing ACE flags. This command
hopefully should work (not tested apart from the syntax, since I don't
have a good testig place, but  please try it and if it doesn't work see
if you can figure out what to change):

Subinacl /service NULL /grant="authenticated users"=QSEILU


You need to run this as administrator of course, but it should hopefully
unlock the NUL device again.

//Magnus



Re: Bug with initDB under windows 2003

From
"dror"
Date:
Hi Magnus,<br />  <br /> After trying to unlock the nul device using:<br />
 Subinacl /service NULL /grant="authenticated users"=QSEILU<br/>  <br /><font color="#ff0000">It doesn't solve the
problem(even after restating the machine) </font><br />  <br /> Here is the new output from running
"Subinacl /service NULL"after the change<br />  <br /> For Administrator:<br />  <br /><br />==============<br
/>+ServiceNULL<br />==============<br />/control=0x0<br />/owner             =system<br />/primary group     =system<br
/>/auditace count   =1<br />/aace =everyone         SYSTEM_AUDIT_ACE_TYPE-0x2<br />       
FAILED_ACCESS_ACE_FLAG-<font>0x80</font>   FAILED_ACCESS_ACE_FLAG-0x0x80<br />        SERVICE_ALL_ACCESS<br />/perm.
acecount   =6<br />/pace =system   ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />       
SERVICE_QUERY_CONFIG-0x1          SERVICE_QUERY_STATUS-0x4           SERVICE_ENUMERATE_DEPEND-0x8<br />       
SERVICE_START-0x10                SERVICE_STOP-0x20                  SERVICE_PAUSE_CONTINUE-0x40        SERVICE<br
/>_INTERROGATE-0x80<br/>        READ_CONTROL-0x20000               SERVICE_USER_DEFINED_CONTROL-0x0100<br />/pace
=builtin\administrators  ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />        SERVICE_ALL_ACCESS<br />/pace
=interactive     ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />        SERVICE_QUERY_CONFIG-0x1          
SERVICE_QUERY_STATUS-0x4          SERVICE_ENUMERATE_DEPEND-0x8<br />       
SERVICE_INTERROGATE-<font>0x80</font>          READ_CONTROL-0x20000              
SERVICE_USER_DEFINED_CONTROL-0x0100<br/>/pace =service  ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />       
SERVICE_QUERY_CONFIG-0x1          SERVICE_QUERY_STATUS-0x4           SERVICE_ENUMERATE_DEPEND-0x8<br />       
SERVICE_INTERROGATE-<font>0x80</font>          READ_CONTROL-0x20000              
SERVICE_USER_DEFINED_CONTROL-0x0100<br/>/pace =builtin\power users      ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br
/>       SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4           SERVICE_ENUMERATE_DEPEND-0x8<br
/>       SERVICE_START-0x10                 SERVICE_STOP-0x20                  SERVICE_PAUSE_CONTINUE-0x40       
SERVICE<br/>_INTERROGATE-0x80<br />        READ_CONTROL-0x20000               SERVICE_USER_DEFINED_CONTROL-0x0100<br
/>/pace=authenticated users      ACCESS_ALLOWED_ACE_TYPE-<font>0x0</font><br />       
SERVICE_QUERY_CONFIG-0x1          SERVICE_QUERY_STATUS-0x4           SERVICE_ENUMERATE_DEPEND-0x8<br />       
SERVICE_INTERROGATE-<font>0x80</font>          READ_CONTROL-0x20000              
SERVICE_USER_DEFINED_CONTROL-0x0100<br/><br />Elapsed Time: 00 00:00:00<br />Done:        1, Modified        0,
Failed       0, Syntax errors        0<br />Last Done  : NULL<br /><br /><br />Anyway,<br /> It obvious that it some
kindof permission issue, but even if this command would have solved the problem it is still mean that the installer
shellrun that command  before calling to <font>initDB, in order to</font> validate that the user can run the initDB (as
itwritten today), Or adding limitation\Warning to the user for known issue and suggest the workaround device,<br /> Or
<br/> Changing the initDB code that it should test the nul device permission before forwarding output to there<br />
Or<br/> Fix the code as I suggested (but unfortunately rejected by Tom).<br />  <br /> Regards<br /> Dror<br /><br
/><br/><hr id="stopSpelling" /><br /> > Subject: RE: [HACKERS] Bug with initDB under windows 2003<br />> Date:
Mon,21 Aug 2006 13:26:11 +0200<br />> From: mha@sollentuna.net<br />> To: dror_b@hotmail.com;
kleptog@svana.org<br/>> CC: pgsql-hackers@postgresql.org<br />> <br />>
> > I'd be interested in seeing the output from the command:<br/>> > > Subinacl /service NULL<br />>
> ><br/>> > > On a system where this does not work.<br />> > ><br />> > <br />>
> Here is the output for "Subinacl /service NULL"<br/>>
> Both, for the Administrator user and for the Postgres user:<br/>> <br />> Thanks.<br />> <br />> <br
/>>> Postgres user:<br />> > >Subinacl /service NULL<br />>
> SeSecurityPrivilege : Access is denied.<br/>>
> WARNING :Unable to set SeSecurityPrivilege privilege. This<br/>> > privilege may be required.<br />>
> Error OpenSCManager : Access is denied.<br/>> <br />>
That's quite normal - the postgres user doesn't have permission to open<br/>>
the SC Manager to view the permissions, because it's not a Power User.<br/>> <br />> <br />>
> Administrator user:<br/>> <br />> This is good. It shows one very clear difference from what I have on a<br
/>>working system, which is:<br />> <br />>
> /pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0<br/>>
>         SERVICE_USER_DEFINED_CONTROL-0x0100<br/>> <br />> On my system, I have:<br />>
/pace =authenticated users      ACCESS_ALLOWED_ACE_TYPE-0x0<br/>>
        SERVICE_QUERY_CONFIG-0x1           SERVICE_QUERY_STATUS-0x4<br/>> <br />>
        SERVICE_ENUMERATE_DEPEND-0x8<br/>>         SERVICE_INTERROGATE-0x80           READ_CONTROL-0x20000<br />>
<br/>>         SERVICE_USER_DEFINED_CONTROL-0x0100<br />> <br />> <br />> <br />>
So this is the problem. Now to figure out how to fix it :-) From what I<br/>>
can tell it simply needs to add back the missing ACE flags. This command<br/>>
hopefully should work (not tested apart from the syntax, since I don't<br/>>
have a good testig place, but  please try it and if it doesn't work see<br/>>
if you can figure out what to change):<br/>> <br />>
Subinacl /service NULL /grant="authenticated users"=QSEILU<br/>> <br />> <br />>
You need to run this as administrator of course, but it should hopefully<br/>> unlock the NUL device again.<br
/>><br />> //Magnus<br />> <br /><br /><br /><hr />Express yourself instantly with Windows Live Messenger! <a
href="http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=joinmsncom/messenger"
target="_new">WindowsLive Messenger!</a>