Bug with initDB under windows 2003

Started by dror barover 19 years ago9 messages
#1dror bar
dror_b@hotmail.com

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 ... okcreating directory E:/Postgres\Data/global ... okcreating directory E:/Postgres\Data/pg_xlog ... okcreating directory E:/Postgres\Data/pg_xlog/archive_status ... okcreating directory E:/Postgres\Data/pg_clog ... okcreating directory E:/Postgres\Data/pg_subtrans ... okcreating directory E:/Postgres\Data/pg_twophase ... okcreating directory E:/Postgres\Data/pg_multixact/members ... okcreating directory E:/Postgres\Data/pg_multixact/offsets ... okcreating directory E:/Postgres\Data/base ... okcreating directory E:/Postgres\Data/base/1 ... okcreating directory E:/Postgres\Data/pg_tblspc ... okselecting default max_connections ... Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.10selecting 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.50creating configuration files ... okcreating template1 database in E:/Postgres\Data/base/1 ... VERSION=8.1.4PGDATA=E:/Postgres\Datashare_path=E:/Program Files/postgres/Database/sharePGPATH=E:/Program Files/postgres/Database/binPOSTGRES_SUPERUSERNAME=V_MYUSERPOSTGRES_BKI=E:/Program Files/postgres/Database/share/postgres.bkiPOSTGRES_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
_________________________________________________________________
Try Live.com: where your online world comes together - with news, sports, weather, and much more.
http://www.live.com/getstarted

#2Martijn van Oosterhout
kleptog@svana.org
In reply to: dror bar (#1)
Re: Bug with initDB under windows 2003

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/

Show quoted text

From each according to his ability. To each according to his ability to litigate.

#3dror
dror_b@hotmail.com
In reply to: Martijn van Oosterhout (#2)
Re: Bug with initDB under windows 2003

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.

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 to in order to test and checked this fix to the CSV.
Regards
Dror
_________________________________________________________________
Try Live.com - your fast, personalized homepage with all the things you care about in one place.
http://www.live.com/getstarted

#4Martijn van Oosterhout
kleptog@svana.org
In reply to: dror (#3)
Re: Bug with initDB under windows 2003

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

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 to in 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/

Show quoted text

From each according to his ability. To each according to his ability to litigate.

#5Magnus Hagander
mha@sollentuna.net
In reply to: Martijn van Oosterhout (#4)
Re: Bug with initDB under windows 2003

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

#6Magnus Hagander
mha@sollentuna.net
In reply to: Magnus Hagander (#5)
Re: Bug with initDB under windows 2003

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

#7dror
dror_b@hotmail.com
In reply to: Magnus Hagander (#6)
Re: Bug with initDB under windows 2003

Hi Magnus,

Magnus Wrote:

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:

Postgres user:

Subinacl /service NULLSeSecurityPrivilege : Access is denied.

WARNING :Unable to set SeSecurityPrivilege privilege. This privilege may be required.Error OpenSCManager : Access is denied.
Elapsed Time: 00 00:00:00Done: 0, Modified 0, Failed 0, Syntax errors 0
----------------------------------------------------------------------------------
Administrator user:

==============+Service NULL==============/control=0x0/owner =system/primary group =system/audit ace count =1/aace =everyone SYSTEM_AUDIT_ACE_TYPE-0x2 FAILED_ACCESS_ACE_FLAG-0x80 FAILED_ACCESS_ACE_FLAG-0x0x80 SERVICE_ALL_ACCESS/perm. ace count =6/pace =system ACCESS_ALLOWED_ACE_TYPE-0x0 SERVICE_QUERY_CONFIG-0x1 SERVICE_QUERY_STATUS-0x4 SERVICE_ENUMERATE_DEPEND-0x8 SERVICE_START-0x10 SERVICE_STOP-0x20 SERVICE_PAUSE_CONTINUE-0x40_INTERROGATE-0x80 READ_CONTROL-0x20000 SERVICE_USER_DEFINED_CONTROL-0x0100/pace =builtin\administrators ACCESS_ALLOWED_ACE_TYPE-0x0 SERVICE_ALL_ACCESS/pace =interactive 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/pace =service 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/pace =authenticated users ACCESS_ALLOWED_ACE_TYPE-0x0 SERVICE_USER_DEFINED_CONTROL-0x0100/pace =builtin\power users ACCESS_ALLOWED_ACE_TYPE-0x0 SERVICE_QUERY_CONFIG-0x1 SERVICE_QUERY_STATUS-0x4 SERVICE_ENUMERATE_DEPEND-0x8 SERVICE_START-0x10 SERVICE_STOP-0x20 SERVICE_PAUSE_CONTINUE-0x40_INTERROGATE-0x80 READ_CONTROL-0x20000 SERVICE_USER_DEFINED_CONTROL-0x0100
Elapsed Time: 00 00:00:00Done: 1, Modified 0, Failed 0, Syntax errors 0Last Done : NULL
----------------------------------------------------------------------------------------------------

As you can see it failed to set SeSecurityPrivilege privilege for the Postgres user.
Regards
Dror;

Subject: Re: [HACKERS] Bug with initDB under windows 2003> Date: Fri, 18 Aug 2006 14:33:58 +0200> From: mha@sollentuna.net> To: mha@sollentuna.net; kleptog@svana.org; dror_b@hotmail.com> CC: pgsql-hackers@postgresql.org> > > > 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> > > ---------------------------(end of broadcast)---------------------------> TIP 4: Have you searched our list archives?> > http://archives.postgresql.org

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

#8Magnus Hagander
mha@sollentuna.net
In reply to: dror (#7)
Re: Bug with initDB under windows 2003

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

#9dror
dror_b@hotmail.com
In reply to: Magnus Hagander (#8)
Re: Bug with initDB under windows 2003

Hi Magnus,

After trying to unlock the nul device using:
Subinacl /service NULL /grant="authenticated users"=QSEILU

It doesn't solve the problem (even after restating the machine)

Here is the new output from running "Subinacl /service NULL" after the change

For Administrator:

==============+Service NULL==============/control=0x0/owner =system/primary group =system/audit ace count =1/aace =everyone SYSTEM_AUDIT_ACE_TYPE-0x2 FAILED_ACCESS_ACE_FLAG-0x80 FAILED_ACCESS_ACE_FLAG-0x0x80 SERVICE_ALL_ACCESS/perm. ace count =6/pace =system ACCESS_ALLOWED_ACE_TYPE-0x0 SERVICE_QUERY_CONFIG-0x1 SERVICE_QUERY_STATUS-0x4 SERVICE_ENUMERATE_DEPEND-0x8 SERVICE_START-0x10 SERVICE_STOP-0x20 SERVICE_PAUSE_CONTINUE-0x40 SERVICE_INTERROGATE-0x80 READ_CONTROL-0x20000 SERVICE_USER_DEFINED_CONTROL-0x0100/pace =builtin\administrators ACCESS_ALLOWED_ACE_TYPE-0x0 SERVICE_ALL_ACCESS/pace =interactive 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/pace =service 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/pace =builtin\power users ACCESS_ALLOWED_ACE_TYPE-0x0 SERVICE_QUERY_CONFIG-0x1 SERVICE_QUERY_STATUS-0x4 SERVICE_ENUMERATE_DEPEND-0x8 SERVICE_START-0x10 SERVICE_STOP-0x20 SERVICE_PAUSE_CONTINUE-0x40 SERVICE_INTERROGATE-0x80 READ_CONTROL-0x20000 SERVICE_USER_DEFINED_CONTROL-0x0100/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
Elapsed Time: 00 00:00:00Done: 1, Modified 0, Failed 0, Syntax errors 0Last Done : NULLAnyway,
It obvious that it some kind of permission issue, but even if this command would have solved the problem it is still mean that the installer shell run that command before calling to initDB, in order to validate that the user can run the initDB (as it written today), Or adding limitation\Warning to the user for known issue and suggest the workaround device,
Or
Changing the initDB code that it should test the nul device permission before forwarding output to there
Or
Fix the code as I suggested (but unfortunately rejected by Tom).

Regards
Dror

Subject: RE: [HACKERS] Bug with initDB under windows 2003> Date: Mon, 21 Aug 2006 13:26:11 +0200> From: mha@sollentuna.net> To: dror_b@hotmail.com; kleptog@svana.org> CC: pgsql-hackers@postgresql.org> > > > 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>

_________________________________________________________________
Try Live.com - your fast, personalized homepage with all the things you care about in one place.
http://www.live.com/getstarted