Setting File Permissions Inside SVS Layers
Have you ever wondered if you can set file permissions in an SVS layer?
So for instance, you wish to auto-activate all layers, but want the group "users" to have read rights, and the group "advanced users" to have read rights?
In a normal XP or Vista environment you probably don't need this. But in a Terminal server environment this can be very useful.
Let's look at an example.
You have a terminal server running with DVS4SBC to get it compliant. On this terminal server you have Office virtualized, and you have Visio virtualised.
Visio adds a button to Excel and Word that users can click to start Visio. Even if they have no rights to start Visio, they will be able to start Visio. But you only want to let users with access to Visio, use it.
In SVS you will not be able to add directory rigths or NTFS rights. Even if you add it to the capturing process it will not be exported to other machines.
So how can you set things up so that a user with Visio rights can see the "launch Visio" button and a user without rights cannot see the button?
First of all.
THIS SCRIPT IS INTENDED FOR ADVANCED SVS ADMINS ONLY. IF YOU DO NOT FEEL COMFORTABLE WITH ADMIN TASKS, PLEASE DO NOT USE THIS. I will not be responsible for damage that occurs for misuse of this kind of scripting as Altiris will also not be responsible.
Go to the www.microsoft.com, and download the program Filemon. This great tool will show you what file is responsible for the button. And because you are on the Microsoft site, also download xcacls.exe
Start Word, and make sure filemon is running. Click on the Visio button, and look in Filemon what file is responsible for the start of Visio. Make a note of this file, you need this file/path later.
Create a group SVS-Visio-Users in your Active Directory. Feel free to add some users to this group.
And now let's work some magic. The script is written in two languages. If it fails on the name of a group, it will automatically go again in English.
Take the script below, and save it as permissions.vbs
REM Set File/Folder Permissions NET LOCALGROUP SVS-Visio-Users IF ERRORLEVEL=1 GOTO ENG :NL Cacls.exe "[Plaats hier het pad naar de folder waar het bestand zich in bevind die je wilt gebruiken zonder de brackets]" /T /E /P SVS-Visio-Users:F GOTO END :ENG Cacls.exe "C:\[Place here the path to the folder where the file is in you wish to protect]" /T /E /P Users:F :END
Now make sure xcacls is in c: windows/system32.
All you need to do now is to make sure that when you activate the program the script runs.
You can do this by using a post activate. A postactivate runs after the layer is activated.
Use the following line:
cscript permissions.vbs "[path to filenae you wish to protect without the brackets]" /T /G SID#S-1-5-32-545:R"
So let's explain what happens when you use that.
- CScript is the standard scripting tool included in all Microsoft Windows versions after 2000.
- Permissions is the vbs script you created before.
- /T and /g are commands from CScript. /G adds the permissions to the file. If you replace /G for /E, the existing permissions are taken of. DO NOT use /E ON CITRIX ENVIRONMENTS. It will stop the file from working completely.
- SID#S-1-5-32-545:R This is the general SID all users can use. In realtime it is replaced with the correct user ID.
And now we will have to face one problem.
After running this script it will prevent SVS from taking the file back inside the layer. If you deactivate or delete the layer, the file will still exist and you have to delete it manually by running the command line with the administrators group instead of the svs-visio-users group.
So what is the best way to do this?
Do not set rights on the c:\program files\application name directory, but set rights on the [_B_]PROGRAMFILES[_E_]
Now rights will be set if the application is activated.
When you export the package the rights will not be in the package. They get lost in the export process. Best way to ensure that the rights are taken inside the package is to set a post activate. The rigths are set after the package is activated.
Regards
ErikW
www.dvs4sbc.com

Comments
Problems
Hi Erik, we are having similar problems with settings rights within SVS Layers. My questions, how do you handle the "Magic Number" within your script? As you have correctly stated, you need to set rights on the physical files and registry keys (i.e. the redirection area). If you have more than one SVS App installed on the machine, the "Magic numbers" differ...
Just my two pennys on that one.
G.
Phil
Use WMI to get your layer
Use WMI to get your layer GUID and then search the registry under software>altiris>FSL for the key that has that guid as the layer ID and wallah you have your magic number.
If a forum post solves your problem please flag is as the solution
Permissions
Thats not the problem, I mean "on the fly" during import or activation. As is, I can get the Magic Number for the RO layer using the SVS API function VzGetLayerAttribute, but during the import phase, there is no RW layer (as yet). Not until the layer has been activated does the RW layer seem to appear.
Another question, have you any experience using the FSL2SetPidRunningFromLayer function. I am attempting to set rights for the layer whilst it is running, i.e. using the CreateProcess API to create a hidden command window (cmd.exe) in a suspended state, getting the PID, and using the PID to notify SVS that this PID is to be "virtualised". Then activating the Process, which calls SecEdit to set permissions. This seems only to "Partly" work. sdb and log file are created. On deactivation of the layer, the log file is "removed", but the sdb, and any files / directories that where "touched" by secedit (although this process was a child process of the "virtualised" cmd.exe) are left, i.e. the application folder. Any clues on this one?
Best regards
Phil
1) I don't see why you
1) I don't see why you can't do this with onPostImport or onPreActivate. The Read/Write layer is there before activate, it's created at the same time (more or less, I'm sure there's some delay if you're using the API) as the Read-Only layer but is empty.
2)'Fraid not, I only use SVS API stuff in C# and I haven't wrapped that function yet (so I haven't used it). I'm a little confused as to what you're doing. Are you trying to edit the permissions of a layer via something in the base (secEdit) and wanting the changes in the base? Seams like your changes are all going to the layer which I'm not sure if you want or not.
If a forum post solves your problem please flag is as the solution
Explanation...
1. Ok, I will have to look into this more closely.
2. I'm a C/C++ man myself, have not gotten into any of the #'s yet (lucky me ;-)). I am trying the make the changes to the layer with a process started from the base, however, most are happening in the base.
This should not (theoretically) be happening if my understanding of the FSL2SetPidRunningFromLayer function.
The managing of permissions within an SVS layer, to say the least is cr*p. If changes are needed, manually editing the ACL files contained within the VSA is just not acceptable, any way, I need to assign permissions to folders and registry keys within the layer. I have attempted to set these rights on the actual physical location (i.e. the redirection areas, for files (C:\fslrdr\%MagicNumber%) and registry keys (HKLM\Software\fslrdr\%MagicNumber%), but there seems to be a problem with recursion when settings rights, ie. inheritance.
After looking the the API, I came across the function FSL2SetPidRunningFromLayer, which if I have understood correctly, takes the PID of a process, and "tells" the SVS that this process is now "part" of the layer, and any changes that this process makes are written to the RO layer of the SVS application.
What I have attempted "seems" to be working, as the SecEdit (an app on all NT systems) that sets permissions on the machine. However, only the (optional) log file is written to the RW layer. The files that are effected by the operation of SecEdit (although set as SetPidRunningFromLayer) are written to the base, as if the process that accesses them is a non-virtualised process.(Editing for example a file in the RW layer with NotePad started from the base).
That's my problem.
Phil
ok so you want changes to
ok so you want changes to happen in the layer so use SVScmd and exec(tute) SecEdit from the layer, I know it's not answering your question about the function but it will do what you want.
As I'm not familiar whit the function I can't really say if there's something else you need to do, but maybe someone else on the Juice does.
If a forum post solves your problem please flag is as the solution
Execute SecEdit?
When you say "execute SecEdit from the layer" does this mean I have to explicitly include the SecEdit.exe in the RO layer of the Application Layer?
No I mean run the execute
No I mean run the execute from layer command in SVScmd, which is SVS's command line tool, you can use the pid or exe and SVS will then run that app as if it was in the layer (even though it's not).
If a forum post solves your problem please flag is as the solution
Would you like to reply?
Login or Register to post your comment.