Issue 87892

Summary: Failure in setting permissions for OOo File Associations in Registry
Product: Installation Reporter: dutchgemini <dutch_gemini>
Component: codeAssignee: Olaf Felka <olaf-openoffice>
Status: CLOSED NOT_AN_OOO_ISSUE QA Contact: issues@installation <issues>
Severity: Trivial    
Priority: P2 CC:, issues, rainerbielefeld_ooo_qa
Version: OOo 3.2.1Keywords: oooqa
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
Correct setting: Acrobat PDF Registry permissions
Failure: OOo 2.4.0 ODT Registry permissions none

Description dutchgemini 2008-04-04 20:56:44 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.
Comment 1 dutchgemini 2008-04-04 20:58:16 UTC
Created attachment 52555 [details]
Correct setting: Acrobat PDF Registry permissions
Comment 2 dutchgemini 2008-04-04 20:59:14 UTC
Created attachment 52556 [details]
Failure: OOo 2.4.0 ODT Registry permissions
Comment 3 dutchgemini 2008-04-11 23:02:09 UTC
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.
Comment 4 dutchgemini 2008-04-13 17:31:14 UTC
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:


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.
Comment 5 dutchgemini 2008-04-13 22:06:45 UTC
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:

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.
Comment 6 Olaf Felka 2008-04-21 12:11:38 UTC
Therefore 'closed'
Comment 7 dutchgemini 2008-08-23 17:49:27 UTC
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).
Comment 8 hagar_de_lest 2008-09-10 13:26:17 UTC
Isn't it a duplicate of Issue 82943 ?
Comment 9 dutchgemini 2008-09-10 13:57:59 UTC
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) 

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 

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.
Comment 10 pavelz 2008-11-01 13:11:30 UTC
I had similar problem and solved it with secedit utility - see
Comment 11 Rainer Bielefeld 2009-09-16 09:42:30 UTC
Related to Issue 82943?
Comment 12 dutchgemini 2009-09-18 09:44:16 UTC
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.
Comment 13 dutchgemini 2009-10-23 13:52:18 UTC
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.
Comment 14 dutchgemini 2011-02-28 08:54:06 UTC
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.