Enhanced Permissions Setting with Windows Installer 5.0

Anith » Enhanced Permissions Setting with Windows Installer 5.0

Anith » Enhanced Permissions Setting with Windows Installer 5.0 — Thu, 05 Mar 2009 13:27:12 GMT

PingBack from http://www.anith.com/?p=15649

re: Enhanced Permissions Setting with Windows Installer 5.0

Dennis — Thu, 05 Mar 2009 23:32:35 GMT

It would have been nice to have allowed for backwards compatibility rather than requiring multiple msis to be built...

re: Enhanced Permissions Setting with Windows Installer 5.0

Kalle Olavi Niemitalo — Sat, 07 Mar 2009 01:16:12 GMT

To the Windows Installer Team:

Is the table really correct? If both tables are used on down-level platforms, I'd expect Windows Installer to ignore the MsiLockPermissionsEx table it doesn't recognize, and use the LockPermissions table present in the package. However your table indicates that the default security settings are applied in this situation.

To Dennis:

In a package that must support pre-7 versions of Windows, do the desired ACLs depend on which version of Windows is being used? If not, the solution seems simple: use LockPermissions if possible, and custom actions otherwise. The package will then install the same way in multiple Windows versions and this does not require Windows Installer to support LockPermissions and MsiLockPermissionsEx in the same package.

Where this breaks down though is merge modules. Now if you're including into your package a merge module that contains the LockPermissions table, and you want to make the next version of the package require Windows 7 and use MsiLockPermissionsEx, you need to either get the vendor of the merge module to also switch to MsiLockPermissionsEx, or hack the tables locally and hope it works. I don't know though; perhaps such a package would be expected to use a chainer instead of merge modules anyway.

re: Enhanced Permissions Setting with Windows Installer 5.0

Windows Installer Team — Mon, 09 Mar 2009 08:05:12 GMT

Dear Kalle, yes you are right. If both tables are used on down-level platforms, then the security settings from LockPermissions table will be applied (and MsiLockPermissionsEx table will simply be ignored). This was a cut and paste mistake while authoring the blog post and has been corrected to reflect the expected behavior now. Thanks for pointing out this discrepancy.