This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Security on HKEY_CLASSES_ROOT keys?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2007
11:50 AM
Security on HKEY_CLASSES_ROOT keys?
Ok, this is really odd.
We just upgraded our install to use InstallShield 2008, and just rebuilt.
When our application gets installed on Vista, everything that the installer writes to HKEY_CLASSES_ROOT (which is mostly a LOT of COM dll registration) appears to be completely locked down in the registry. As an administrator on the machine, I can see all the keys, but when I click on one and it tries to get values, I get an Access Denied error. All previously existing keys in the registry are fine. HKEY_LOCAL_MACHINE is also fine.
In fact, as an administrator, I cannot even change the permissions on the keys that it installed.
When our install was on a previous version of installshield, this never occurred.
Any ideas what is going on here? I'm stumped.
We just upgraded our install to use InstallShield 2008, and just rebuilt.
When our application gets installed on Vista, everything that the installer writes to HKEY_CLASSES_ROOT (which is mostly a LOT of COM dll registration) appears to be completely locked down in the registry. As an administrator on the machine, I can see all the keys, but when I click on one and it tries to get values, I get an Access Denied error. All previously existing keys in the registry are fine. HKEY_LOCAL_MACHINE is also fine.
In fact, as an administrator, I cannot even change the permissions on the keys that it installed.
When our install was on a previous version of installshield, this never occurred.
Any ideas what is going on here? I'm stumped.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2007
12:01 PM
What method did you use to populate the registry? ( MSI SelfReg, ISSeflReg, COM tables, Registry table, Custom Actions? )
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2007
12:12 PM
Most of the data is being extracted from the com components at build time by installshield, so it looks like its going into the registry table.
We also have a few registry keys that we manually added, also appearing in the registry table.
We also have a few registry keys that we manually added, also appearing in the registry table.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2007
01:56 PM
well, after more research, I have discovered that something removed ALL permissions from HKEY_CLASSES_ROOT (but not from sub keys) on my machine that i'm testing with. Now the bigger question - what removed the permissions?
I'll continue testing and see if I can find out what did it.
I'll continue testing and see if I can find out what did it.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2007
02:02 PM
I hope you aren't using the LockPermissions table! 🙂
Windows Installer's permissions pattern is so badly broken I don't know where to start. The two main problems is let's say some object ( directory or registry key ) as a bunch of permission assigments and you want to make a change. MSI will replace all of the assignments with your new assignment and not preserve any of the originals.
To make it worse, it doesn't understand permission propogation ( inheritance ).
I once received a CD from a software vendor that was labeled 7.5A with insturctions "DESTROY THE 7.5 MEDIA".
Why? Because they put LockPermissions on HKEY_CLASSES_ROOT and it destroyed the system so badly that you had to be very smart in the registry to restore the state or otherwise just reimage the machine.
Windows Installer's permissions pattern is so badly broken I don't know where to start. The two main problems is let's say some object ( directory or registry key ) as a bunch of permission assigments and you want to make a change. MSI will replace all of the assignments with your new assignment and not preserve any of the originals.
To make it worse, it doesn't understand permission propogation ( inheritance ).
I once received a CD from a software vendor that was labeled 7.5A with insturctions "DESTROY THE 7.5 MEDIA".
Why? Because they put LockPermissions on HKEY_CLASSES_ROOT and it destroyed the system so badly that you had to be very smart in the registry to restore the state or otherwise just reimage the machine.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2007
02:13 PM
thats good to know. fortunately, we are not using the LockPermissions table. There is one row in it, and it looks like its coming from a merge module, but it is referencing a folder.
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)