Apache OpenOffice (AOO) Bugzilla – Issue 87892
Failure in setting permissions for OOo File Associations in Registry
Last modified: 2017-05-20 09:44:25 UTC
I have installed OOo 2.4.0 (Italian, file name OOo_2.4.0_Win32Intel_install_wJRE_it.exe) on top of 2.3.1 (Italian). Everything went fine and I was able to use it without problems. Since I run multiple accounts on my XP Home SP2 Italian PC (I am Administrator, the others are Users), when I entered my wife's account I noticed that all the OOo file associations were gone (instead of showing the OpenOffice icons or saying it was an OpenOffice Document type, it simply said "ODT File"). OOo was available on the Start menu and ran fine, and I could read/write files created previously without problems. But I could not open any OOo file from Windows Explorer. Thinking about an installer mistake, first repaired and then did the installation again but without success. I uninstalled and reinstalled without success either. I also tried (in the failing account) to re-associate the ODT file to OOo's Writer but it didn't work, Windows did not even save it. Finally I discovered the problem: the OOo 2.4.0 Windows Installation fails to register the file extensions correctly, or better said, does not add the correct permissions to the registry entries. The file association entry in the registry is usually installed with sufficient permissions for letting all accounts read the keys and as such you normally find entries like 'Administrators', 'CREATOR OWNER', 'SYSTEM' and 'Users' (seen this looking for instance at \\HKCR\.pdf). The installer of OOo 2.4.0, instead, sets permissions only for 'Administrator' and 'SYSTEM', failing to add 'CREATOR OWNER' but the biggest problem is that 'Users' is also missing. Therefore, no other account apart from the 'Administrators' group can read (or set) the file associations for OOo. I scanned many OOo entries and ALL of them have the same problem.
Created attachment 52555 [details] Correct setting: Acrobat PDF Registry permissions
Created attachment 52556 [details] Failure: OOo 2.4.0 ODT Registry permissions
Must correct initial comment: I had v2.3.0 Italian and *NOT* v2.3.1 Italian. Have uninstalled v2.4.0 Italian, cleaned the registry (with CCLeaner) and have downloaded v2.3.1 Italian (OOo_2.3.1_Win32Intel_install_wJRE_it.exe). This release has also the same problem. I started REGEDIT on the failing account and indeed I cannot read the registry key (no permissions). Back on v2.4.0 Italian working around the problem now (start OOo and then open; Explorer shell start not possible). Awaiting a solution.
Have done further investigation and found a similar if not same problem mentioned on issue 53811 which seems to be in the 'not solved' state. Forum reports that can be associated to this problem: - http://www.oooforum.org/forum/viewtopic.phtml?t=26408 - http://www.oooforum.org/forum/viewtopic.phtml?t=26059 My first install was 2.2.0 Italian and have installed the updates till 2.3.0 Italian. I have skipper 2.3.1 Italian and went for 2.4.0 Italian directly. All have 1 thing in common and that the problem occurs on Windows XP with multiple accounts including non administrator/power users accounts. During the installation I chose 'Every account of this computer' and noticed that the 'Only for this account ()' was missing the name of the actual account.
Problem SOLVED. The solution consisted in restoring the standard permissions on the HKEY_CLASSES_ROOT node of the registry. On one forum someone mentioned that after installing Acrobat Reader 8.1, which I have indeed installed after OOo 2.3.0, the root node of HKEY_CLASSES_ROOT had the permissions scrambled (see here: http://forum.soft32.com/win3/Restore- default-registry-permissions-ftopict57863.html). As turned out, on HKCR I had only 'Everyone' with 'Full control'. I have restored them to what appears to be the standard, following indications found on another site, that is: Administrators: 'Full control' on 'Selected key and all sub-keys' CREATOR OWNER: 'Full control' on 'Sub-keys only' Everyone: 'Read control' on 'Selected key and all sub-keys' SYSTEM: 'Full control' on 'Selected key and all sub-keys' I use XP HOME. Owners of XP Professional should verify/set the 'Power Users' group as well.
Therefore 'closed'
I have recently told that I thought it was caused by another application and as such I have (falsly) considered it closed. Yesterday (finally) I have accepted to update my OOo2.4.0 Italian to OOo2.4.1 Italian using the internal update notification component. Apart from downloading the file twice(?) for me, it went trough install without further problems, wasn't that my other accounts could *AGAIN* not start any OOo document via Windows Explorer. A quick test revealed the exact same problem I had after upgrading to 2.4.0, that is all my permissions on HKCR were replaced by a single entry for 'Everyone' and all the others gone. Just before the update to 2.4.1 everything was working fine. I have redone the install from scratch and I have the same problem. Since no other software was installed aside, I am quite convinced it can be isolated to the settings embedded in the MSI Windows Installer package. No difference exists between installing with JRE or without (my case).
Isn't it a duplicate of Issue 82943 ?
Not a duplicate but one is child of the other. The problem described in Issue 82943 is (from reading the description) confined to the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\... - OOo related keys (and subkeys) only. What I am describing is that the problem is really caused by the damage the installer produces in the *root* of HKCR and *not* to the OOo related keys (as a matter of fact, no other keys are affected if not by propagation). And unfortunately this bug affects *all* applications that register extensions under HKCR and that are being used on a PC with multiple non-administrative accounts. As you can find out, many applications do not hardcode permissions in the subkeys but rely on the permissions set walking HKCR down to the subkey/leaf where the data is located. Hope this will be solved in v3.
I had similar problem and solved it with secedit utility - see http://support.microsoft.com/kb/313222
Related to Issue 82943?
This question was raised Sept 10 2008 by hagar_de_lest and, as I replied, it is indeed related to Issue 82943 but as I also mentioned, this last Issue is showing the symptoms of the problem. The *BIG* and *SERIOUS* problem is the totally incorrect registry permissions on the *root* of HKCR impede non-admins to read the registry and use the correct file associations of all applications on the PC. Unfortunately this problem is not solved and I had to correct it again after the same symptoms came up as soon as I install the latest OO available. I keep the correct settings in a *.reg file and have a copy posted on my wordpress blog as well.
Problem solved. Problem fixed using OOo_3.1.1_Win32Intel_install_wJRE_it.exe (Italian). I monitored the Registry during installation of 3.1.1 over 3.1.0 (the one having the problem first seen in 2.4.0). All permissions on root HKCR have been maintained their original values.
WARNING: This serious bug has returned in OO 3.2.1. I recently upgraded OO to 3.2.1 (Italian) and have *AGAIN* the problem that the HKCR permissions are all messed up. In the mean time, I have *NOT INSTALLED* any other software except OO so I can exclude 100% that another software may be responsible for this problem. Needless to say that I really am getting frustrated redoing my HKCR permission setting every time I have an update or upgrade of OO. This problem *MUST* be solved. Dutch