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

From: Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>
To: David Fleischhauer <dgfleisch(at)gmail(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: permission issues with PostgreSQL 9.2 EnterpriseDB one-click installer on windows 7 causes initcluster to fail
Date: 2013-12-18 07:58:13
Message-ID: CANFyU95zs82y2tt8AP7cBsSU24gKXaRDzha6A-nwMKVxgyGM5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Dec 16, 2013 at 9:26 PM, David Fleischhauer <dgfleisch(at)gmail(dot)com>wrote:

> I have added my comments inline as well:
>
>
> On Mon, Dec 16, 2013 at 1:35 AM, Sandeep Thakkar <
> sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>
>> 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(at)gmail(dot)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:\)
>>
>
> E:\>icacls E:\
> E:\ BUILTIN\Administrators:(OI)(CI)(F)
>
> Successfully processed 1 files; Failed processing 0 files
>
> I understand your reasoning that initcluster.vbs should only deal with
> permissions related to the data directory, but in order to create the data
> cluster, you need to run initdb which is in the bin directory. I am
> assuming my issue is related to the initdb command using dll libraries in
> the bin directory that it cannot find because the current logged in user
> does not have read rights to the bin directory. Giving read rights to the
> bin directory before running initcluster.vbs fixes my issue. This issue
> affects the default GUI installer too. The GUI installer never sets
> permissions for the bin directory. One thing to note, all of my testing
> has been done with a data directory that is not a sibling of the bin
> directory. I do not think this is necessary to reproduce the problem but I
> have done that to ensure the icacls commands on the data directory does not
> interfere with the permissions of the bin directory and mask the problem
> somehow.
>
>>
>>>
>> You mean your installation location and the data directory location was
on different drives? Or just the different paths in 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".
>>
>
> Yeah, the new flag is a good idea and changing the script is ok, its just
> when it was changed, a really weird corner case that was explicitly handled
> before is no longer being handled.
>

I executed the following command:
icacls "E:" /grant "NT AUTHORITY\NetworkService":(NP)(RX)

and this command worked fine. I used the double quotes around the drive and
it does not end with slash. So, my guess is that the comment in the script
is not relevant anymore? and the issue#2 also appears because of the
permissions?

>
>
>>>
>>
>>> ' 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?
>>
>>
> I can reproduce this issue both ways. If you run the GUI installer with
> the E: drive completely empty and with the administrators group as the only
> group with permissions as I have given in the 'icacls E:\' command, you
> will first run into issue #1. To get issue #2, what I have done is
> explicitly create the postgres install directory if it does not exist and
> set read and write permissions on the directory. I do this before running
> the installer.
>
> I can run the same exact icacls command initcluster.vbs runs, and it
> passes with flying colors (for both 9.2.4 and 9.2.5). I even have saved
> off the radxxxx.bat file and have run that and it still passes with flying
> colors. The issue crops up when running the batch file within vb. Oddly
> enough, if I run the vb script a second time (not through the installer),
> it will give the correct permissions. So I think there is a bug in vb that
> initcluster.vbs is exploiting with the 'icacls "E:" ...' command. I have
> created a vb script that only has the doCmd(...) method in it and I pass in
> my own icacls command and I still get this issue.
>
>>
>>> 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
>>
>>
>

--
Sandeep Thakkar

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Serge Negodyuck 2013-12-18 14:20:48 Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby
Previous Message bneumeier 2013-12-17 17:10:01 BUG #8684: Tables with custom range domain type cannot be analyzed