SWV Layer ACL customization
|Article:HOWTO26092|||||Created: 2010-05-10|||||Updated: 2010-05-10|||||Article URL http://www.symantec.com/docs/HOWTO26092|
IntroductionWhen building an application layer, all the file / folder and registry entries will inherit the permissions that are assigned to the parent directory/key they are created in. This can cause problems because an administrator account is generally used to build a VSA, and the machine(s) the VSA will be deployed to, will usually be locked down in the domain it’s a member of. When the layer is activated the domain user will not have sufficient privileges to run the application in the layer. To make sure this does not happen we need to write the desired permissions into the layers File / Registry Read-only sections which will provide appropriate access to domain users. * We will use c:\program files, and 5,6 for the folder names in this example. For simplicity we will grant the local machine users group to this folder and all respective registry settings with full control rights. This will only be applicable to the VSA and will not change anything on the system. This document describes the process for customizing the ACL on both the file/folder and registry areas of an SVS layer. This document does not provide advanced usage training for the 3rd party tools required.
Cacls (To set file/folder permissions) – Part of Windows OS, or Xcacls. Download from:
SubInACL.exe (To set registry permissions). Download from:
Overview (The first thing we need to do is review the structure of an SVS layer.)
1. An SVS layer consists of two sections for both Files and Registry.
o Read-only (The base layer. This is locked)
o Writeable (This is the user specific area, any changes made by a user are saved here and are not a permanent part of the layer.)
2. The files and registry values are not stored in the regular system areas. When a layer is activated the virtualization creates a merged view that creates a “virtual” entry in the location where these contents would have been stored with a conventional installation.
o Files/Folders are stored in C:\fslrdr. Each layer on a computer will have two folders in this location. They will be two subsequent numbers. (e.g. 1, 2)
o Registry settings are stored in HKLM\Software\fslrdr, in the same numbered keys as the respective application layer.
o Folders can have letter names as well.
o The first folder, in this case 1, represents the Read-only section.
3. If more than one layer is present on the machine, you can determine which folders belong to it by checking the registry.
o Go to HKLM\System\Controlset001\Services\FSLX
o Each key will be numbered and every pair of keys will represent one application layer.
o Select any key and look at the Name value to find out what application this is. (Hopefully you gave your layer a descriptive name at creation time)
Preparing CACLS and SubInACL.exe CACLS.EXE
4. Using the steps described in #3 in the Overview section above, identify the folder names for the VSA to be updated.
5. Browse to the first folder and note the path to the program files location. It will have some extra characters appended to the front and end of the name. (e.g. [_B_]PROGRAMFILES[_E_])
6. Now all we need to do is write the cacls string to modify the ACL of this location and all subfolders and files to give the local user group full control. For this example it looks like this:
o cacls c:\fslrdr\5\[_B_]PROGRAMFILES[_E_] /E /T /C /P "users":F
7. After downloading and installing this program browse to its installation folder and copy/paste the executable somewhere in the system path so that you can run it from any location.
8. We already know the corresponding numbers for our layer. (See Overview, step 3) All we need to do is create a simple batch file to initiate this process.
9. For this example I called my file, acl.bat and it contains the following two lines.
o subinacl /subkeyreg HKEY_LOCAL_MACHINE\Software\fslrdr\5 /grant=users=f
o subinacl /subkeyreg HKEY_LOCAL_MACHINE\Software\fslrdr\6 /grant=users=f
10. This will apply the same full control access to the local users group on the above two keys, as well as all child keys.
11. That’s it, the hard part is done. All we need to do know is to get these settings written into our VSA Read-only area.
How to create a VSA with a customized ACL
12. When creating a new layer all we need to do is capture the layer through the command prompt, so that we have control of when the capture process is over. We will also have control of what goes into the layer.
13. Go through the usual steps to create a layer, accept point to the executable for the command prompt when asked for the Program Name.
14. Complete the steps and the command prompt will launch.
15. Either change the directory to where the application installer is located and run it from the command prompt, or drag and drop its icon onto the command prompt window and press enter to launch it.
16. When the installer completes, the capture process will not end because it’s waiting for the command prompt to close. Here is where we add our customization piece.
o Since this is a new layer, the folder/key names did not exist when preparing, so you can quickly check what new folders got created and update your scripts as needed.
o Run the CACLS command you prepared in step 6.
o Run the SubInACL.exe batch file you prepared in step 9.
17. Type exit and press enter. The command prompt closes, the capture process ends, and you have a layer with a customized ACL.
How to update VSA layer ACL data
18. The steps here are identical to those when building a new VSA, except for a couple differences.
19. First we need to deactivate the layer and reset it.
20. Select the normal steps to update an existing layer.
21. As in step 13 above, use the command prompt as the Program Name.
22. When the command prompt opens, all you need to do is run the command and batch as was done in step 16.
23. Type exit and press enter. The command prompt closes, the capture process ends, and you have an upgraded layer with a customized ACL.
24. If this is done using a VSA that contains data in the Writable are of the VSA, it will not get updated. The later must be reset to receive the new permissions from the Read-only area.
25. Note: In these situations make sure any important data that was added to the Writable area is backed up before performing a reset.
Article URL http://www.symantec.com/docs/HOWTO26092