Re: permission issues with PostgreSQL 9.2 EnterpriseDB one-click installer on windows 7 causes initcluster to fail - Mailing list pgsql-bugs

From Sandeep Thakkar
Subject Re: permission issues with PostgreSQL 9.2 EnterpriseDB one-click installer on windows 7 causes initcluster to fail
Date
Msg-id CANFyU94CBZ6gkHJAoSiFq6fQeprD+EZ+mu4_gM2ZpM47pmF_XA@mail.gmail.com
Whole thread Raw
In response to permission issues with PostgreSQL 9.2 EnterpriseDB one-click installer on windows 7 causes initcluster to fail  (david fleischhauer <dgfleisch@gmail.com>)
Responses Re: permission issues with PostgreSQL 9.2 EnterpriseDB one-click installer on windows 7 causes initcluster to fail  (David Fleischhauer <dgfleisch@gmail.com>)
List pgsql-bugs
Hi David

Thanks for checking and reporting this. Before we proceed, we would like
some more information. Please see the comments inline.


On Fri, Dec 13, 2013 at 11:00 PM, david fleischhauer <dgfleisch@gmail.com>wrote:

> I have noted two bugs dealing with permissions with the EnterpriseDB
> one-click installer.  Both are similar cases:
>
>
> 1.  Permissions are not given to the PostgreSQL bin directory.  If I try
> to install postgres on a drive with limited permissions (for my test, only
> the 'Administrators' group had permissions), I get an error saying
> "libintl-8.dll" is missing.  That file is located in the postgres bin
> directory.  The issue is that your initcluster.vbs script only gives
> permissions for the data directory and the parent directories of the data
> directory.  In order for postgres to install correctly, permissions need to
> be added for the bin directory.
>

initcluster.vbs is supposed to deal only with the cluster directory and
it's permissions. Could you list the ACL on the E:\ drive please? Command
line output will do. (icacls E:\)

>
>

> 2.  Permissions are not properly given to the PostgreSQL data directory's
> root drive in PostgreSQL version 9.2.5 and up.  In PostgreSQL 9.2.4 there
> is a comment in the initcluster.vbs script saying:
>

Yes, In 9.2.5, initcluster script has undergone some changes because lot of
people did not want the initcluster to change the permissions on the
complete parent path of the data directory as icacls would take a lot of
time to do this if that path contains huge number of files. Hence, from
9.2.5, by default the initcluster will change the permissions of just the
'data' directory. If user wants the ACL to be edited on the complete path,
then he can do it with a new command line option "--enable_acledit 1".

>
>

>     ' Drive letter must not be surrounded by double-quotes and ends with
> slash (\)
>     ' "icacls" fails on the drives with (NP) flag
>
> In version 9.2.5, the initcluster.vbs script has been changed and the
> above corner case is not taken care of.  Again, to reproduce this issue, I
> set the E drive of my machine to only give permissions to the
> 'Administrators' group and my E drive was completely empty.  I also had to
> fixed issue #1 to get this issue to pop up.  The error I am getting from
> the logfile is:
>
>     The database cluster will be initialized with locale "English_United
> States.1252".
>     The default text search configuration will be set to "english".
>
>     fixing permissions on existing directory E:/dir/data ... ok
>     creating subdirectories ... initdb: could not create directory
> "E:/dir": File exists
>     initdb: removing contents of data directory "E:/dir/data"
>
>     Called Die(Failed to initialise the database cluster with initdb)...
>     Failed to initialise the database cluster with initdb
>
> Here are the slight differences between the icacls command to grant
> permissions to the root drive in 9.2.4 and 9.2.5:
>
>     9.2.4:    icacls E:\ /grant ...
>     9.2.5:    icacls "E:" /grant ...
>
> As your comment shows, having quotes around 'E:' and also not including
> the slash will cause an issue, both of which are not taken care of in the
> 9.2.5 icacls command.
>

Sure. Will look into this. You ran into this issue during the installation?
Or when you run the initcluster script manually?


>
> Hopefully I have clearly stated the issues.  If these issues have not been
> reported and there are any issues understanding what I wrote, feel free to
> reply to this email.
>
> thanks,
> David
>



--
Sandeep Thakkar

pgsql-bugs by date:

Previous
From: John R Pierce
Date:
Subject: Re: BUG #8682: sqlstate = 28000
Next
From: Anit Chakkarwar
Date:
Subject: Re: BUG #8681: column 'n_tup_del' of pg_stat_user_tables doesn't change in case of truncate