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 CANFyU96zQP4ymd1-Op164wmioy7ekwj2S6qZJQ2XoDrswLnVAA@mail.gmail.com
Whole thread Raw
In response to Re: 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
List pgsql-bugs
Thanks. This will be taken care of in the next updates. But, please note
that all this ACL changes will be done only when "--enable_acledit 1"
switch is provided on the command line when the installer is run.


On Wed, Dec 18, 2013 at 8:31 PM, David Fleischhauer <dgfleisch@gmail.com>wrote:

>
>
>
> On Wed, Dec 18, 2013 at 2:58 AM, Sandeep Thakkar <
> sandeep.thakkar@enterprisedb.com> wrote:
>
>>
>>
>>
>> On Mon, Dec 16, 2013 at 9:26 PM, David Fleischhauer <dgfleisch@gmail.com>wrote:
>>
>>> I have added my comments inline as well:
>>>
>>>
>>> On Mon, Dec 16, 2013 at 1:35 AM, Sandeep Thakkar <
>>> sandeep.thakkar@enterprisedb.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@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:\)
>>>>
>>>
>>>     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:\?
>>
>
> They can be on different drive if you want them to be, or they can just be
> on different paths in the same directory.  For instance:
>
>            Postgres Bin Dir:      E:\dir\PostgreSQL\9.2\bin
>            Postgres Data Dir:    E:\dir\data
>
> the point is to get a situation where initcluster.vbs does not give
> permissions to bin directory's parent (i.e. E:\dir\PostgreSQL\9.2).
> initcluster.vbs would only give permissions to that directory if the data
> dir is a sibling of the bin directory (i.e. E:\dir\PostgreSQL\9.2\data)
>
> Here is a list of steps to follow to recreate the issue:
>
> 1.  Empty out your E:\ drive so that there is nothing left in it.
> 2.  Right-click on the E:\ drive in an explorer window and click
> "Properties"
> 3.  Click on the "Security" tab
> 4.  Click "Edit..."
> 5.  Click "Remove" for all "Group or User Names" except for
> "Administrators (<cpuname>\Administrators)".  If Administrators is not
> listed,, add it.
> 6.  Click "Apply" and close out of all windows
> 7.  Double click on the postgres installer =>
> postgresql-9.2.5-1-windows-x64.exe.  Make sure the installer is version
> 9.2.5 or later
> 8.  When prompted for the installation directory, type in:
> E:\dir\PostgreSQL\9.2\
> 9.  When prompted for the data directory, type in: E:\dir\data
> 10. Answer all the other questions.  The installation should fail due to a
> libintl-8.dll file not being found (issue #1). The file should be located
> in the postgres bin directory
> 11. Uninstall PostgreSQL 9.2
> 12. Repeat steps 1-6
> 13. Run the following commands:
>               mkdir "E:\dir\PostgreSQL\9.2\"
>               icacls "E:\dir\PostgreSQL\9.2\" /grant "NT
> AUTHORITY\NetworkService":"(OI)(CI)RX"
>               icacls "E:\dir\PostgreSQL\9.2\" /grant "<logged-in
> user>":"(OI)(CI)RX"
> 14. Repeat steps 7-10.  The installation should fail again, but give you a
> different error (issue #2).
> 15. Repeat steps 2 and 3.  You should only see "Administrators
> (<cpuname>\Administrators)" under "Group or User Names".  Notice that no
> permissions were granted for the "NT AUTHORITY\NetworkService" or the
> logged in user.  If you go to "E:\dir" and look at its security tab under
> properties, you will see the logged in user present under "Group or User
> Names", so the icacls command succeeded for "E:\dir".
>
> Now go into your temp directory and look at install-postgresql.log.  You
> will see the following error:
>
>
>     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
>
> You will also see a little bit further up:
>
>     Executing icacls to ensure the <logged-in user> account can read the
> path E:
>         Executing batch file 'radAC52112.bat'...
>         processed file: E:
>
>     Successfully processed 1 files; Failed processing 0 files
>
> Which leads you to believe it correctly gave permissions to the E: drive,
> but as we confirmed earlier, it did not.  If you follow these steps,
> hopefully you will be able to recreate my issues.
>
>
>>
>>>>> 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?
>>
>
> If you open up a cmd windows and type icacls  "E:" /grant "NT
> AUTHORITY\NetworkService":(NP)(RX), it will pass and grant you the
> correct permissions.  How to get the error is to remove all permissions
> from the drive except for the administrators group and run the
> DoCmd(strCmd) method in VB.  Here is the method for reference:
>
>     ' Execute a command
>     Function DoCmd(strCmd)
>         Dim objBatchFile
>         Set objBatchFile = objTempFolder.CreateTextFile(strBatchFile, True)
>         objBatchFile.WriteLine "@ECHO OFF"
>         objBatchFile.WriteLine strCmd & " > """ & strOutputFile & """ 2>&1"
>         objBatchFile.WriteLine "EXIT /B %ERRORLEVEL%"
>         objBatchFile.Close
>         WScript.Echo "    Executing batch file '" & strBatchFile & "'..."
>         DoCmd = objShell.Run(objTempFolder.Path & "\" & strBatchFile, 0,
> True)
>         If objFso.FileExists(objTempFolder.Path & "\" & strBatchFile) =
> True Then
>             objFso.DeleteFile objTempFolder.Path & "\" & strBatchFile, True
>         Else
>             WScript.Echo "    Batch file '" & strBatchFile & "' does not
> exist..."
>         End If
>         If objFso.FileExists(strOutputFile) = True Then
>             Dim objOutputFile
>             Set objOutputFile = objFso.OpenTextFile(strOutputFile,
> ForReading)
>             WScript.Echo "    " & objOutputFile.ReadAll
>             objOutputFile.Close
>             objFso.DeleteFile strOutputFile, True
>         Else
>             WScript.Echo "    Output file does not exists..."
>         End If
>     End Function
>
> It first creates a batch file and writes three lines to it:
>
>     @echo off
>     icacls ...
>     EXIT /B %ERRORLEVEL%
>
> then it calls:
>
>     DoCmd = objShell.Run(objTempFolder.Path & "\" & strBatchFile, 0, True)
>
> if you pass in 'icacls  "E:" /grant "NT AUTHORITY\NetworkService":(NP)(RX)'
> to the DoCmd with an empty E:\ drive and the correct permissions, you will
> see that the icacls command is executed and outputs that the command
> passes.  However, if you go back and look at the permissions on the E:\
> drive, you will see that the permissions actually did not get set.  I
> believe this is an issue with vb itself as the icacls command should not
> pass when it obviously is failing.
>
>
>>>
>>>>>
>>>>
>>>>>     ' 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
>>
>>
>
>



--
Sandeep Thakkar

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #8893: Precompiler ECPG doesn't check Var-List in Select corrrect.
Next
From: Anjali Arora
Date:
Subject: Re: BUG #8891: Duplicate Primary Key