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

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(at)gmail(dot)com>wrote:

>
>
>
> On Wed, Dec 18, 2013 at 2:58 AM, Sandeep Thakkar <
> sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>
>>
>>
>>
>> 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:\?
>>
>
> 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