Enhanced Permissions Setting with Windows Installer 5.0

Setting appropriate permissions for an object is one of the core operations in creating an application installer. One of the most frequent pieces of feedback has been to provide enhanced capabilities around securing resources installed on the system. MsiLockPermissionsEx Table in Windows 7 enhances the functionality over LockPermissions Table. With MsiLockPermissionsEx table , users now have the ability to set access permissions on objects impacted by the application install that previously required using custom actions or other methods outside of Windows Installer.

· Expanding the set of permissions that can be applied to a resource by incorporating the Security Descriptor Definition Language(SDDL) in Windows Installer. This allows the security settings for an object to be more flexible, including;

o Ability to apply Deny ACLs to objects

o Indicate inheritance properties for permissions

o Expand the set of well-known SIDs

o Ability to set Owner, Group, and SACLs to the objects in addition to the regular access permissions

· Security settings can be applied to services as well in addition to Files, Folders, Registry keys

· Ability to apply permissions specific to user accounts – including accounts that are newly created on the system during the course of installation

FormattedSDDLText is a new column data type used by the SDDLText field of the MsiLockPermissionsEx Table to secure a selected object.

Q: How does new MsiLockPermissionsEx table change the semantics or behavior of the older LockPermissions table?

A: Packages using the older LockPermissions table will continue to work as expected. However, we encourage you to author your packages targeted for Windows 7 and above to use the new MsiLockPermissionsEx table to take advantage of the power and flexibility provided by SDDL while customizing security settings for your resources.

Q: Can I author both LockPermissions and MsiLockPermissionsEx tables in my package?

A: No, in the interest of simplifying authoring and avoiding collisions, it is not allowed to have both LockPermissions and MsiLockPermissionsEx tables in the same package. If both tables are present, the installation will fail. ICE 104 verifies that only one of the two tables: MsiLockPermissionsEx or LockPermissions is present in the package.

Q: What happens if two conditions in different rows evaluate to true for the same LockObject/Table pair in MsiLockPermissionsEx table? Which SDDLText will be applied?

A: If a LockObject/Table pair has multiple conditional expressions that evaluate to true, the installation will fail. So, be careful while authoring your conditions: if you have more than one security setting in your package for an object – make sure the corresponding conditions are mutually exclusive.

Q: What happens if the SDDL specified in MsiLockPermissionsEx is incorrect, or if the user does not have permissions to apply the security settings described by the SDDL?

A: The installation fails if Windows Installer is unable to resolve the SDDL specified in the MsiLockPermissionsEx table into a valid security descriptor, or if the user doesn’t have the permissions to apply those settings, unless the package is blessed by an administrator.

Q: When is the resolution of SDDLText into the binary security descriptor done?

A: Unlike the older LockPermissions table, the resolution of permissions into the binary security descriptor for MsiLockPermissionsEx is done during the execution phase, at the time when an object is actually being installed. This is important because it means you can even set security settings referencing a new user account that is being created as part of the installation as long as the account creation is scheduled before the object is installed.

Q: Now that I can set security attributes on a service installed by a package via the MsiLockPermissionsEx table, can I do so with the LockPermissions table as well?

A: No, if you wish to set security attributes on a service, you will have to use the MsiLockPermissionsEx table. The behavior and semantics of the LockPermissions table will not change.

Q: My product has already been released. Can I use MsiLockPermissionsEx table to secure objects that are already installed? Can I use this feature to secure objects via a patch?

A: Similar to the LockPermissions table, you can use a patch to secure objects that are being installed on the machine with MsiLockPermissionsEx table, including objects that replace existing ones on the machine as part of the installation. If an object is not installed as part of the current installation, security settings specified in MsiLockPermissionsEx will not be applied to it. It should be kept in mind that a patch that includes either of these two tables – MsiLockPermissionsEx or LockPermissions – will be marked as not uninstallable.

Q: Will there be an ICE validation test to help me author the new table?

A: Yes, ICE 104 is being introduced to help validate the MsiLockPermissionsEx table.

Q: Will this feature be available on down-level platforms?

A: No, as of now, this feature is being introduced only in Windows 7. Down-level platforms will ignore MsiLockPermissionsEx table, if present. See the table below for behavior on various platforms:

	Only LockPermissions	Only MsiLockPermissionsEx	Both tables	Neither
Windows 7 and above	Security settings from LockPermissions table are applied	Security settings from MsiLockPermissionsEx table are applied	The installation fails if both tables are present.	*Default security settings are applied.
Down-level platforms	Security settings from LockPermissions table are applied	*Default security settings are applied.	Security settings from LockPermissions table are applied	*Default security settings are applied.

 

*“Default security settings” mean that if an object does not replace an existing object, it receives no explicit security descriptor: the access to the new object is based on the attributes of its parent or container object. If an object replaces an existing object on the system, the replacement gets the security settings of the object it replaces. If the replaced object had no explicit security descriptor, the access to the new object is based on the attributes of its parent or container object.

[Author: Ashish Awasthi]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm

Comments

• Anonymous
  March 04, 2009
  PingBack from http://www.anith.com/?p=15649

• Anonymous
  March 05, 2009
  It would have been nice to have allowed for backwards compatibility rather than requiring multiple msis to be built...

• Anonymous
  March 06, 2009
  The comment has been removed

• Anonymous
  March 08, 2009
  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.