Redigera

Dela via

Securing Resources

  • Artikel

The capability of the Windows Installer to set access permissions on services, files, created folders, and registry entries can help make installation applications more secure. The use of the MsiLockPermissionsEx or LockPermissions tables to secure resources is one of the recommended Guidelines for Authoring Secure Installations. The MsiLockPermissionsEx table can enable a package author to secure a resource without having to write a custom action.

Beginning with packages developed for Windows Installer 5.0, the MsiLockPermissionsEx table should replace the use of the LockPermissions table. The extended functionality provided by the MsiLockPermissionsEx table enables a package to secure Windows Services, files, folders, and registry keys. A package should not contain both the MsiLockPermissionsEx and the LockPermissions tables.

Windows Installer 4.5 and earlier ignores the MsiLockPermissionsEx table. Beginning with Windows Installer 5.0, the installation fails with an error message 1941 if the package contains both a LockPermissions table and MsiLockPermissionsEx table. Existing installation packages that contain only the LockPermissions table can be still be installed using Windows Installer 5.0.

Windows Installer 5.0 processes the information in the MsiLockPermissionsEx table when it runs the InstallFiles, InstallServices, WriteRegistryValues and CreateFolders standard actions. A securable object must be installed or reinstalled to be secured and it is not possible to append an Access Control List (ACL) to an existing object without reinstalling that object.

To specify the service, file, directory, or registry key that is to be secured, enter the identifying information in the LockObject and Table fields of the MsiLockPermissionsEx table. An object is identified by it's primary key in the ServiceInstall Table, File Table, Registry Table, or CreateFolder Table.

To request that specified permissions apply to an object, enter a valid security descriptor string in the SDDLText field of the MsiLockPermissionsEx table using valid security descriptor definition language (SDDL). The MsiLockPermissionsEx table can specify a security descriptor that denies permissions, specifies inheritance of permissions from a parent resource, or specifies the permissions of a new account. For a list of all the permissions that can be granted, denied, or inherited see ACE Strings. Windows Installer 5.0 extends the set of available security identifiers (SIDs.) For a list of the valid SIDs, see SID Strings.

Note

If you want to configure the security descriptor of a parent resource to specify that that its permissions be inherited by child objects, your installer must apply permissions to the parent resource before it creates the child objects. If your installer creates the child objects before it applies the inheritable permissions to the parent resource, the permissions of the parent resource will not propagate to the child objects.

Beginning with Windows Installer 5.0, the FormattedSDDLText data type extends the Formatted data type. The Windows Installer validates that the FormattedSDDLText string entered in the SDDLText column of the MsiLockPermissionsEx table conforms to the Security Descriptor String Format.

Windows Installer 4.5 or earlier: Not supported. The MsiLockPermissionsEx table and FormattedSDDLText data type are available beginning with Windows Installer 5.0.