Quantcast

Heat and COM Registry Permissions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Heat and COM Registry Permissions

leviwilson
I have been using heat.exe to generate my version 3 information for files.  For my COM objects, I noticed a strange behavior.  Heat.exe seems to properly setup the registry keys that I need, but the permissions on the CLSID\[my guid] keys differ than those that would be set if I used regsvr32 on the same DLL.  Has anyone else experienced this?  Here are the permissions that get setup for one of my CLSID\[GUID] key that is associated with my COM object:

Name             Permission    Inherited From
------------         -------------------  ---------------------
local\Admin      Full Control   CLASSES_ROOT\CLSID
SYSTEM         Full Control   CLASSES_ROOT\CLSID
Administrators  Full Control   CLASSES_ROOT\CLSID
RESTRICTED   Read            CLASSES_ROOT\CLSID

When it is registered by regsvr32 I get the following:

Name             Permission    Inherited From
------------         -------------------  --------------------
Users               Read            Parent Object
Power Users    Special         Parent Object
local\Admin      Full Control   CLASSES_ROOT\CLSID
SYSTEM         Full Control    CLASSES_ROOT\CLSID
SYSTEM         Full Control    Parent Object
Administrators  Full Control   CLASSES_ROOT\CLSID
Administrators  Full Control   Parent Object
CREATOR OWNER  Full Control  Parent Object

What happens in my program, is when our service calls CoCreateInstance on the COM object, it fails that that class is not registered.  The service is running as local system.  However, when instantiating a COM object from a process run as local\admin it works fine.  Am I not setting something up properly?


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat and COM Registry Permissions

leviwilson
Hmm, all seems to be well if I set ALLUSERS=1 <grin />.  Apparently the default of an MSI is a per-user installation.  So this isn't an issue with heat or registry permissions at all, but user error.  Is this typical in most installations where you have to explicitly set ALLUSERS=1?

On 2/12/07, Levi Wilson <[hidden email]> wrote:
I have been using heat.exe to generate my version 3 information for files.  For my COM objects, I noticed a strange behavior.  Heat.exe seems to properly setup the registry keys that I need, but the permissions on the CLSID\[my guid] keys differ than those that would be set if I used regsvr32 on the same DLL.  Has anyone else experienced this?  Here are the permissions that get setup for one of my CLSID\[GUID] key that is associated with my COM object:

Name             Permission    Inherited From
------------         -------------------  ---------------------
local\Admin      Full Control   CLASSES_ROOT\CLSID
SYSTEM         Full Control   CLASSES_ROOT\CLSID
Administrators  Full Control   CLASSES_ROOT\CLSID
RESTRICTED   Read            CLASSES_ROOT\CLSID

When it is registered by regsvr32 I get the following:

Name             Permission    Inherited From
------------         -------------------  --------------------
Users               Read            Parent Object
Power Users    Special         Parent Object
local\Admin      Full Control   CLASSES_ROOT\CLSID
SYSTEM         Full Control    CLASSES_ROOT\CLSID
SYSTEM         Full Control    Parent Object
Administrators  Full Control   CLASSES_ROOT\CLSID
Administrators  Full Control   Parent Object
CREATOR OWNER  Full Control  Parent Object

What happens in my program, is when our service calls CoCreateInstance on the COM object, it fails that that class is not registered.  The service is running as local system.  However, when instantiating a COM object from a process run as local\admin it works fine.  Am I not setting something up properly?



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat and COM Registry Permissions

Wilson, Phil
Well it's the usual and required behavior for a per-user install to add the entries to the current user's hive.  It's not particularly secure if a per-user install adds system-wide COM registration so that anyone on the system can use it. It's regsvr32 that's rather limited here because it doesn't know if you intend a per-user or per-machine install (although people have built regsvr programs that do).

Phil Wilson


From: [hidden email] [mailto:[hidden email]] On Behalf Of Levi Wilson
Sent: Monday, February 12, 2007 1:28 PM
To: [hidden email]
Subject: Re: [WiX-users] Heat and COM Registry Permissions

Hmm, all seems to be well if I set ALLUSERS=1 <grin />.  Apparently the default of an MSI is a per-user installation.  So this isn't an issue with heat or registry permissions at all, but user error.  Is this typical in most installations where you have to explicitly set ALLUSERS=1?

On 2/12/07, Levi Wilson <[hidden email]> wrote:
I have been using heat.exe to generate my version 3 information for files.  For my COM objects, I noticed a strange behavior.  Heat.exe seems to properly setup the registry keys that I need, but the permissions on the CLSID\[my guid] keys differ than those that would be set if I used regsvr32 on the same DLL.  Has anyone else experienced this?  Here are the permissions that get setup for one of my CLSID\[GUID] key that is associated with my COM object:

Name             Permission    Inherited From
------------         -------------------  ---------------------
local\Admin      Full Control   CLASSES_ROOT\CLSID
SYSTEM         Full Control   CLASSES_ROOT\CLSID
Administrators  Full Control   CLASSES_ROOT\CLSID
RESTRICTED   Read            CLASSES_ROOT\CLSID

When it is registered by regsvr32 I get the following:

Name             Permission    Inherited From
------------         -------------------  --------------------
Users               Read            Parent Object
Power Users    Special         Parent Object
local\Admin      Full Control   CLASSES_ROOT\CLSID
SYSTEM         Full Control    CLASSES_ROOT\CLSID
SYSTEM         Full Control    Parent Object
Administrators  Full Control   CLASSES_ROOT\CLSID
Administrators  Full Control   Parent Object
CREATOR OWNER  Full Control  Parent Object

What happens in my program, is when our service calls CoCreateInstance on the COM object, it fails that that class is not registered.  The service is running as local system.  However, when instantiating a COM object from a process run as local\admin it works fine.  Am I not setting something up properly?



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Loading...