Setting Permissions in Windows Installer: MSILockPermissionsEX and ISLockPermissions

One of the fundamental problems with Windows Installer (MSI) versions before 5.0 was an inability to change permissions reliably on an object in an installer (such as a registry key, file, or folder). When the MSI installs that object, the default behaviour is that the object will inherit the permissions from its parent folder or key.

If we set permissions on an object in the UI in InstallShield 2009 and earlier, an entry was added to the LockPermissions table; during installation the object’s access control list (ACL) would be changed to whatever was set in the table entry, completely disregarding any inheritance.

The only way to reflect the inheritance was to install the desired resource with the standard inherited ACL and then call a custom action to carry out the modification to the access control list.

In MSI 5.0, Microsoft has finally addressed this lacuna, plugging the gap with the MSILockPermissionsEX table, which has extra functionality in it. However, this table is ignored when the MSI is installed on a system with a Windows Installer version prior to 5.0, so it cannot be used when the installer needs to be installed on systems earlier than Windows 7. To add insult to injury, version 5.0 of Windows Installer will fail an installation if both the MSILockPermissionsEX table and the LockPermissions table are present in an MSI.

However, one of the new functionalities in InstallShield 2010 and later versions is a “standard” custom action and associated table ISLockPermissions. Now, as long as the option “Locked-Down Permissions” is set to “Use Custom InstallShield Handling”, if we set permissions on files, folders, or registry entries in the InstallShield UI, the default behaviour is that inheritance will be reflected, as well as some extra bonuses (such as the ability to use a security identifier (SID) in the permissions definition). The major benefit over MSILockPermissionsEX however, is that it works on all versions of Windows Installer, and thus Windows 7 and other versions.

4 comments on “Setting Permissions in Windows Installer: MSILockPermissionsEX and ISLockPermissions

  1. Dan on   # Reply

    I use the custom InstallShield Handling generally, but it cannot (at this time) handle 64-bit registry permissions. Luckily I don’t have any 64-bit apps that require custom registry permissions at the moment, but it’s only a matter of time before I see one. Would love to see that fixed!

  2. Marcin Otorowski on   # Reply

    I am having issues with inheritance of ACE when using MsiLockPermissionsEx table. No matter what DACL flag (P, AI, AR or combinations of them) I set, Windows Installer always replaces existing permissions and protects from inheritance, so parent container’s permissions are not inherited by my object. This behavior has been observed on different machines with different test packages. Is it a bug or am I missing something?

  3. Bertalan Varnai on   # Reply

    I have the same issues!

  4. InstallShield Team on   # Reply

    Hi Bertalan, The InstallShield default for this is to use the ISLockPermissions table which supports inheritance. Let us know how this works for you. Thanks for visiting InstallTalk!

Leave a Reply

Your email address will not be published. Required fields are marked *