Securing Files, Folders, and Registry Keys in a Locked-Down Environment

InstallShield 2016 Express Edition

InstallShield offers different ways to secure files, folders, and registry keys for end users who run your product in a locked-down environment:

•

Traditional Windows Installer handling—InstallShield stores permission information for your product in the LockPermissions table of the .msi database.

•

Custom InstallShield handling—InstallShield stores permission information for your product in the ISLockPermissions table of the .msi database. InstallShield also adds custom actions to your project.

These methods enable you to assign permissions for a file, folder, or registry key to specific groups and users. For example, you may assign Read, Write, and Delete permissions for a particular file to the Administrators group, but only Read permissions for all of the users in a different group.

Determining Which Option to Use

The following table compares the different types of methods for setting permissions.

Comparison of Different Ways to Secure Objects (Files, Folders, and Registry Keys) in a Locked-Down Environment

Comparison Category

Explanation of Available Support

Well-known security identifiers (SIDs)

•

Traditional Windows Installer handling—Supports a limited number of SIDs (Administrators, Everyone).

•

Custom InstallShield handling—Supports many SIDs (Administrators, Authenticated Users, Creator Owner, Everyone, Guests, Interactive, Local Service, Local System, Network Service, Power Users, Remote Desktop Users, and Users).

Localized names for SIDs

•

Traditional Windows Installer handling—Does not support localized names for SIDs; if you try to use a localized name, the installation fails.

•

Custom InstallShield handling—Supports localized names for all of the supported well-known SIDs (Administrators, Authenticated Users, Creator Owner, Everyone, Guests, Interactive, Local Service, Local System, Network Service, Power Users, Remote Desktop Users, and Users).

Ability to deny specific permissions

•

Traditional Windows Installer handling—Not supported. This handling lets you set specific permissions; you cannot deny permissions. Thus, you can give a user read-only access to a file. However, you cannot prevent a user from having read-only access.

•

Custom InstallShield handling—Supported. This option lets you indicate whether you want to deny a user or group from having the permissions that you are specifying.

Effect on permissions that already exist

•

Traditional Windows Installer handling—Existing permissions may be deleted. For example, if permissions are already set for a folder on the target system for the Everyone user, and your installation needs to set permissions for the Administrators user, this option would allow you to set permissions for the Administrators user. However, the existing permissions for Everyone would be deleted.

•

Custom InstallShield handling—This option lets you add permissions to a file, folder, or registry key that already exists on the target system, without deleting any existing permissions for that object. For example, if permissions are already set for a folder on the target system for the Everyone user, and your installation needs to set permissions for the Administrators user, these options would allow you to set permissions for the Administrators user without deleting the existing permissions for the Everyone user.

Ability to propagate permissions to child objects (subfolders, files, and subkeys)

•

Traditional Windows Installer handling—Not supported. If you want to configure permissions for a subfolder or a file in a folder (or a subkey under a registry key), the parent that is created on the target system automatically inherits the permissions of its child.

•

Custom InstallShield handling—Supported. This option lets you configure permissions for a folder (or a registry key), and indicate whether you want the permissions to be applied to all of the folder’s subfolders and files (or the registry key’s subkeys).

Ability to set permissions for a new user that is being created during the installation

•

Traditional Windows Installer handling—Not supported.

•

Custom InstallShield handling—Supported. If a new user is created during the installation, you can configure permissions for that user.

Neither option lets you set permissions for objects that are not being installed as part of your installation.

Learning More about the Custom InstallShield Handling Option or the Traditional Windows Installer Handling Option

In Express projects, you need to specify whether you want to use the custom InstallShield handling or the Windows Installer handling. To learn how, see Selecting the Locked-Down Permissions Type for a Project.

To learn how to set permissions for a file or folder using either of these options, see Configuring Permissions for Files and Folders. For information on setting permissions for a registry key using either of these options, see Configuring Permissions for Registry Keys.

Securing Files, Folders, and Registry Keys in a Locked-Down Environment

InstallShield 2016 Express Edition Help Library

May 2017