I note the earlier message from Steve (Mar 23) about this.
OK, changing permissions will be in a later release? When?
I have an app I need to deploy now that needs to make entries at run-time. Currently I have these set up in HKLM\Software\myco\myapp but they could be anywhere.
Testing was fine (we were all administrators ...duh!) user testing has highlighted the problem.
Are there any keys GUARANTEED to read/write for all users?
Can I achieve this (in HKLM\...) with a custom action?
Can Windows Installer do it at all? If so can you tell me which table edits I need to make (say with ORCA) to the msi file created with AI.
Pete
Suggested Articles
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
-
amalia
Hi Pete,
Your problem is caused by the fact that AI doesn't set any kind of permissions for the registry entries. When these entries are created on the target machine, they inherit permissions from their parents.
You have two solutions:
1. write your registry values with a custom action instead of AI. Indeed, you have to place your registry keys in HKLM.
2. after building your package with AI, edit it with Orca. Add a new table named "LockPermissions" (Tables->AddTable); for every row in the registry table, add a row in this one. The rows from LockPermissions table have the next structure:
- LockObject - the name from the first column in Registry table (e.g. TestReg)
- Table - allways put here the string "Registry"
- Domain - leave it empty
- User - put the string "Everyone"
- Permissions - put the number 268435456. This number is the privilege constant GENERIC_ALL. You can add here any other privilege constant that suites best your goal - you can find these values in Platform SDK.
In the near future, we'll add registry permissions support in Advanced Installer.
Regards,
Amalia
Your problem is caused by the fact that AI doesn't set any kind of permissions for the registry entries. When these entries are created on the target machine, they inherit permissions from their parents.
You have two solutions:
1. write your registry values with a custom action instead of AI. Indeed, you have to place your registry keys in HKLM.
2. after building your package with AI, edit it with Orca. Add a new table named "LockPermissions" (Tables->AddTable); for every row in the registry table, add a row in this one. The rows from LockPermissions table have the next structure:
- LockObject - the name from the first column in Registry table (e.g. TestReg)
- Table - allways put here the string "Registry"
- Domain - leave it empty
- User - put the string "Everyone"
- Permissions - put the number 268435456. This number is the privilege constant GENERIC_ALL. You can add here any other privilege constant that suites best your goal - you can find these values in Platform SDK.
In the near future, we'll add registry permissions support in Advanced Installer.
Regards,
Amalia
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
Hi Amalia
Thanks for that. I used the second method (ORCA edit) and it does what I need perfectly. Some points of clarification please...
Is "Everyone" recognised by all OS platforms?
The install creates a key stucture
HKLM\SOFTWARE\myco\myapp\name1=value1
HKLM\SOFTWARE\myco\myapp\name2=value2 etc.
Looking at the parent keys after install I notice that both "myco" and "myapp" have "Everyone" permissions. Not really a problem but is there some way I can restrict this access to just "myapp" and its name/value pairs?
Is there a way of creating the key HKLM\SOFTWARE\myco\myapp and setting its permission for all name/values to inherit and that thus allows an (non admin) application to both add and edit name/value at run-time?
What happens if I don't include all name/value pairs in the LockPermissions table?
In AI, why can't I add "empty" string values? The OK button is disabled.
Pete
Thanks for that. I used the second method (ORCA edit) and it does what I need perfectly. Some points of clarification please...
Is "Everyone" recognised by all OS platforms?
The install creates a key stucture
HKLM\SOFTWARE\myco\myapp\name1=value1
HKLM\SOFTWARE\myco\myapp\name2=value2 etc.
Looking at the parent keys after install I notice that both "myco" and "myapp" have "Everyone" permissions. Not really a problem but is there some way I can restrict this access to just "myapp" and its name/value pairs?
Is there a way of creating the key HKLM\SOFTWARE\myco\myapp and setting its permission for all name/values to inherit and that thus allows an (non admin) application to both add and edit name/value at run-time?
What happens if I don't include all name/value pairs in the LockPermissions table?
In AI, why can't I add "empty" string values? The OK button is disabled.
Pete
-
amalia
Hi Pete
1. "Everyone" is recognized by Windows Installer 2.0, no matter the OS (Advanced Installer creates packages only for Windows Installer 2.0 )
2. If you want read/write permission only for "myapp" add a new registry value in "myco"; in LockPermissions table add permissions only for the myapp key.
3.If you have many values in myapp, you have to include in LockPermissions table only one of them - all myapp values will have the same permission rights. The idea is to set permissions only for the key and all its subkeys and values will inherit its permissions.
4. What would be the purpose of a value with no data?
Regards
Amalia
1. "Everyone" is recognized by Windows Installer 2.0, no matter the OS (Advanced Installer creates packages only for Windows Installer 2.0 )
2. If you want read/write permission only for "myapp" add a new registry value in "myco"; in LockPermissions table add permissions only for the myapp key.
3.If you have many values in myapp, you have to include in LockPermissions table only one of them - all myapp values will have the same permission rights. The idea is to set permissions only for the key and all its subkeys and values will inherit its permissions.
4. What would be the purpose of a value with no data?
Regards
Amalia
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
Thanks, but yet more...
1.) The "everyone" question really meant - Is the group "everyone" always present in the security system? Specifically would older NT systems know about it? Or maybe this doesn't matter as long as the key gets the GENERIC_ALL permission?
2,3,4) I needed to get an install out urgently (done today) so I used your feedback in a rather "brute force" way simply because it works. I had the primary install create all the keys that might possibly be needed by the application so the (non-admin) user of the app could save values at run-time. That's why I asked about empty string values.
What I am really seeking is an elegant way to do the following...
Create a key with some name/values in a primary install and set permissions so that an application without admin rights can both add and edit name/values under that key. If this can be done then (4) is irrelevant as the app can check for the presence of a name/value and create on-demand if needed. On uninstall the key should be removed - including the name/values it did not create.
Maybe we can follow this up by direct email as perhaps other forum users don't need all this detail?
Thanks for your help though - it's much appreciated.
Pete
1.) The "everyone" question really meant - Is the group "everyone" always present in the security system? Specifically would older NT systems know about it? Or maybe this doesn't matter as long as the key gets the GENERIC_ALL permission?
2,3,4) I needed to get an install out urgently (done today) so I used your feedback in a rather "brute force" way simply because it works. I had the primary install create all the keys that might possibly be needed by the application so the (non-admin) user of the app could save values at run-time. That's why I asked about empty string values.
What I am really seeking is an elegant way to do the following...
Create a key with some name/values in a primary install and set permissions so that an application without admin rights can both add and edit name/values under that key. If this can be done then (4) is irrelevant as the app can check for the presence of a name/value and create on-demand if needed. On uninstall the key should be removed - including the name/values it did not create.
Maybe we can follow this up by direct email as perhaps other forum users don't need all this detail?
Thanks for your help though - it's much appreciated.
Pete
-
amalia
Hi Pete,
1. "Everyone" is a generic group to which belong any user or group. It is always present on any NT System.
2. To set the security of only one key you need a row in the registry table for that key. To force the AI to create that row, check the "Delete (if present) at uninstall" option from the key properties. This will allow the deletion, at uninstall, of all the subkeys and values of that key, no matter if they were created during installation or by your application at run-time. Now you have a row in the Registry table for your interest key - add permissions for it in the LockPermissions table.
Regards
Amalia
1. "Everyone" is a generic group to which belong any user or group. It is always present on any NT System.
2. To set the security of only one key you need a row in the registry table for that key. To force the AI to create that row, check the "Delete (if present) at uninstall" option from the key properties. This will allow the deletion, at uninstall, of all the subkeys and values of that key, no matter if they were created during installation or by your application at run-time. Now you have a row in the Registry table for your interest key - add permissions for it in the LockPermissions table.
Regards
Amalia
-
Pete Furness
- Posts: 16
- Joined: Fri Feb 20, 2004 9:34 am
- Location: SURREY, UK
Finally got round to modifying my "brute force" install as per your suggestions. It does not seem to be working as you indicated though.
Install set up to create...
HKLM\SOFTWARE\myco\myapp\name1=value1
HKLM\SOFTWARE\myco\myapp\name2=value2
etc.
I then use ORCA to Add the LockPermissions table and add "everyone" access for the KEY
HKLM\SOFTWARE\myco\myapp
and the FIRST name/value pair
HKLM\SOFTWARE\myco\myapp\name1=value1
This works fine and all name/value pairs under
HKLM\SOFTWARE\myco\myapp
are read/write by non-admin users of the app
However the key
HKLM\SOFTWARE\myco
is also read/write
I have tried adding a name/value to this key and not adding it to the LockPermissions table as you suggested and also the same strategy with another key. Neither seem to prevent the undesired r/w access to
HKLM\SOFTWARE\myco
What am I doing wrong here?
Pete
Install set up to create...
HKLM\SOFTWARE\myco\myapp\name1=value1
HKLM\SOFTWARE\myco\myapp\name2=value2
etc.
I then use ORCA to Add the LockPermissions table and add "everyone" access for the KEY
HKLM\SOFTWARE\myco\myapp
and the FIRST name/value pair
HKLM\SOFTWARE\myco\myapp\name1=value1
This works fine and all name/value pairs under
HKLM\SOFTWARE\myco\myapp
are read/write by non-admin users of the app
However the key
HKLM\SOFTWARE\myco
is also read/write
I have tried adding a name/value to this key and not adding it to the LockPermissions table as you suggested and also the same strategy with another key. Neither seem to prevent the undesired r/w access to
HKLM\SOFTWARE\myco
What am I doing wrong here?
Pete