Windows Permissions and Security Considerations on Windows 95, 98, and ME are virtually nonexistent since these operating systems do not support Access Control.

On all other versions, there are three primary areas for consideration regarding how the Windows operating system security can potentially affect your licensed software.

1. Virgin Registry Data is written to the registry - which is a controlled resource.

2. Registry Alias Files are written to the registry - which is a controlled resource.

3. Hidden Alias Files you design can potentially be located in system folders - which are a controlled resource.

If your target audience is guaranteed to have at least default "Power User" permissions, Windows permissions becomes a non-issue since they will have permission to read and write to any location the ClientProtector may need. On the other hand if your target audience may have only "restricted user" or less access - you must carefully consider the following:

Virgin Registry Data

Virgin registry data can be located in one of four different root keys in the Windows registry. The only one that you have virtually guaranteed access to under all levels of user permissions is the HKEY_CURRENT_USER root key. There is however, a significant drawback to using this key: Its values are only relative to the currently logged in user, so switching users will effectively cause any values under this key to "disappear" for any user but the "writer". However, this is usually not an issue since Virgin Registry Data is (generally) only written the first time the ClientProtector is started for a particular license. As long as the first time your software starts the ClientProtector for a particular license the user has sufficient privileges to write to the chosen key, there should be no problems. You should however, be aware of it since if the time comes that the ClientProtector needs to write to the Virgin Key again and it cannot your license may fail.

Registry Alias Files

Registry Alias Files can be located in one of three root keys in the windows registry. Like the Virgin Registry Data, the only one that you have virtually guaranteed access to under all levels of user permissions is the HKEY_CURRENT_USER root key. There is however, a major drawback to using this key: Its values are only relative to the currently logged in user, so switching users will effectively cause any values under this key to "disappear" for any user but the "writer". Unlike the Virgin Key - Registry Alias Files are read and written continuously as the license is manipulated - so you must ensure that you have guaranteed access to any Registry Alias Files you create.

Hidden Alias Files

Since you have the option of placing hidden alias files in several different directories, you must consider if your user will have the necessary Windows permissions to write to these directories. By default, some versions of Windows (2000 / NT / XP) may need administrator rights to be able to write files to some system folders. If they do not have the permissions needed to write to these folders, and you choose to store alias files there, your license will fail.

Solutions

The topic of Access Control under Windows is an extremely vast subject and well beyond the scope of this help file. We recommend if in doubt, always refer to the source - the MSDN. Please see: "Access Control" at the MSDN for more information.
(See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/access_control.asp)

The best way to deal with these potential problems is:

1. Require your program to be installed by an Administrator or configure your installer to perform secured actions using elevated privileges. This is usually required anyway since you will have to register the SSCProt.dll COM server and any other ActiveX controls of your own and this is also controlled under Windows.

2. During installation, manipulate the Access Control List (ACL) for any resources (registry hives, folders) you need during licensing execution to allow all users permission to read and write. This can be done a number of ways. Many installer packages provide integrated ACL manipulation routines that you can use for this purpose. Another popular way to manipulate the ACLs is to use a third party program. A popular (and free) tool to do this during installation is "SetACL - CmdLine". This program can be executed during installation right from your installer on the command line and will quietly set all your necessary permissions. (See: http://setacl.sourceforge.net/)

In order to successfully set ACLs, you will of course need all the path and key information of the resources that intend on manipulating permissions for. It is critically important that if you do decide to manipulate the ACL of the registry that you set the permissions on the correct key but do not create the sub-key value names themselves.

Example:

You specify a Registry Alias File with the root key being HKEY_LOCAL_MACHINE. You give the Registry Alias File a GUID of {01B5DDC5-0800-4ED8-A59E-AE0730410893}. At run-time, when this Registry Alias File is written it will be written as:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{01B5DDC5-0800-4ED8-A59E-AE0730410893}\

It will have a sub-key named:

\InProcServer32

Therefore, if you choose to manipulate the ACL during installation, so that this key can be used as an Alias File location, you must create the key: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{01B5DDC5-0800-4ED8-A59E-AE0730410893}\, and set its permission to "all access", but do not create the sub-key: \InProcServer32.

Likewise, for Virgin Registry data, create and manipulate the permission level to "all access" for the "Virgin Key Path", but do not create the Virgin Key Value Name sub-key.

For more detailed information on where registry Alias Files are written,  please see Virgin Registry Data and Registry Alias Files.

We recognize that manipulating the ACLs in this way may be undesirable in some circumstances, or beyond your project time budget since doing so correctly requires a fair amount of Windows security programming knowledge and must be done correctly or you could impair the operating system. So, as an alternative, we suggest a simpler way to deal with this potential Windows permissions problem with a minimum of effort and time. This simpler approach is not as secure, but is trivial to implement and requires no manipulation of ACLs.

1. Don't use Virgin Registry Data. Simply turn the option off. -OR- Require that an administrator run the program for the first time. If you choose this second option, you may also need them to recover the license if that is ever necessary because of file tampering etc.

2. Use only hidden or steganographic alias files.

3. Set hidden alias files locations to the Main License File Folder or the Common Documents Folder only. (Steganographic alias files are always in the Main License File Folder by default.)

Using this simpler method, as long as your software has write access to the Main License File Folder (probably one you explicitly created), there will be no Windows permissions problems at all. As always, make sure you thoroughly test your software relative to all the levels of users you anticipate will have to use your programs.