When you set permissions, you are specifying what level of access the user has to the folder and its files and what users can do within that folder such as save, delete, or read files.
If you would like to know how to set permissions through Powershell Script, then I would recommend you to read my new blog entry here:
http://msiworld.blogspot.com/2012/01/my-first-powershell-script.html
There are six standard permission types which apply to files and folders in Windows XP/Windows 7:
Each level represents a different set of actions users can perform. See the table below for more information.
For folders you can also set your own unique permissions or create a variation of any of the standard permission levels. Within each of the permission levels are many possible variations.
The following table represents the available standard permission types with their descriptions:
Full Control - Permits the user(s) to:
Modify - Permits the user(s) to:
Read & Execute - Permits the user(s) to:
List Folder Contents - Permits the user(s) to:
Read - Permits the user(s) to:
Write - The Read permissions, plus permits the user(s) to:
You can set permission to folders in following ways:
Full Control - Permits the user(s) to:
Modify - Permits the user(s) to:
Read & Execute - Permits the user(s) to:
List Folder Contents - Permits the user(s) to:
Read - Permits the user(s) to:
Write - The Read permissions, plus permits the user(s) to:
You can set permission to folders in following ways:
SECEDIT:
SECEDIT command-line tool can be used to impose group policy object settings upon a target workstation immediately.To use Secedit to give permission in your package, perform the following steps:
Go to Run and type MMC.
A Console will open up as shown in the below picture.
Go to File -> and click on Add / Remove Snap in.
The Add / Remove Snap in window opens up as shown in the below picture.
After this Click on Add...
Add standalone Snap in console opens up as shown in the below picture.
Choose Security Template from the list of Snap in, and click on Add.
The Security template will be added to the console.
You can see the File System, with all the listed directories on the right. This is shown in below picture.
Now, delete all files on right.
Right click and click on Add File, browse and select the required directory to give permission to.
Similarly you can give permission to registry too.
Now, delete all files on right.
Right click and click on Add File, browse and select the required directory to give permission to.
Similarly you can give permission to registry too.
Click on OK and save this template as .inf (such as {PackageName}.inf) file.
Now we have to include this file in the package.
Add this file to %Windir%\security\templates folder.
Use the following Custom Action in your package to implement Secedit.
Use Execute Program from Destination Custom Action.
secedit /configure /db "[security]Database\{PackageName}.sdb" /cfg "[security]templates\{PackageName}.inf" /log "[security]logs\{PackageName}.log" /quiet
Here [security] refers to the security folder is C:\Windows or %Windir%\Security. It is always good to use directory instead of hardcoded paths.{PackageName} refers to the name you would like to give to your .inf file, to your log file you create and to the .sdb file you create.
Note that this will create .sdb file in %windir%\security\Database folder and .log file in %windir%\security\logs folder. So while un-installation of package you need to remember to delete these files from the folder. You can do that by using remove file table.
XCACLS/ICACLS:
XCACLS or Extended Change Access Control List tool, is an advanced version of CACLS, the difference being that we do not have to answer Yes/No prompts in XCACLS. CACLS and XCACLS are tools which are used to modify the ACLs (Access Control Lists), by which in turn we are modifying the folder permissions for users in windows. ICACLS is another tool like XCACLS.CACLS is installed in all users machine in System32 folder.
XCACLS ships with the Windows NT Resource Kit or can be easily downloaded from net. XCACLS allows you to set permissions to the same granular level of control that you have with the GUI.
CACLS Syntax
CACLS filename [/T] [/E] [/C] [/G user:perm] [/R user [...]] [/P user:perm [...]] [/D user [...]]
| filename | Displays ACLs. |
| /T | Changes ACLs of specified files in the current directory and all subdirectories. |
| /E | Edit ACL instead of replacing it. |
| /C | Continue on access denied errors. |
| /G user:perm | Grant specified user access rights. Perm can be: R Read C Change (write) F Full control |
| /R user | Revoke specified user's access rights (only valid with /E). |
| /P user:perm | Replace specified user's access rights. Perm can be: N None R Read C Change (write) F Full control |
| /D user | Deny specified user access. |
Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.
XCACLS Syntax
XCACLS filename [/T] [/E] [/C] [/G user:perm;spec] [/R user [...]][/P user:perm;spec [...]] [/D user [...]] [/Y]
| filename | Displays ACLs. |
| /T | Changes ACLs of specified files in the current directory and all subdirectories. |
| /E | Edit ACL instead of replacing it. |
| /C | Continue on access denied errors. |
| /G user:perm;spec | Grant specified user access rights. Perm can be: R Read C Change (write) F Full control P Change Permissions (Special access) O Take Ownership (Special access) X EXecute (Special access) E REad (Special access) W Write (Special access) D Delete (Special access) Spec can be the same as perm and will only be applied to a directory. In this case, Perm will be used for file inheritence in this directory. If not omitted: Spec=Perm. Special values for Spec only: T NoT Specified (for file inherit, only for dirs valid) At least one access right has to follow! Entries between ';' and T will be ignored! |
| /R user | Revoke specified user's access rights. |
| /P user:perm;spec | Replace specified user's access rights. for access right specification see /G option |
| /D user | Deny specified user access. |
| /Y | Replace user's rights without verify |
Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.
You can combine access rights.
Example of XCACLS can be:
xcacls "[INSTALLDIR]FOLDER" /e /g users:ewxd;ewx
Usage for ICACLS
ICACLS "[INSTALLDIR]FOLDER" /T /grant USERS:M
LockPermission table:
LockPermission table can be also used to give permission to files, folders and registries.With the help of Lockpermission table you can give permission to only those users who already exist on the computer or domain.
For giving permission through LockPermission table follow the below procedure:
On the File section in Installation expert (You can do the same with Registry too) , Either go to file or the directory (depending on to which you want to give permission) and click on Details. There will be a permission tab there. For giving permission to file you will get the below screen where there will be a permissions tab among other tabs as shown in the picture. If you have chosen directory then there will only be a permissions tab. Click on Add. In the domain, you can mention the domain of the user for which permissions are to be set. You can either give a standalone machine or a domain name. I have used an environment variable here [%USERDOMAIN] which will pick the domain at run time for the user for which the package is being installed. The user which you can set can be Administrator, Everyone or Logged on User. I have selected every one here.
After that you can select the permissions from below what all permissions you want to give to the user. Click ok and the permissions work is over.
Now when you go to the LockPermissions table in Tables section, you can see the following columns there:
Lock Object, Table, Domain, User and permission.
Lock Object and Table column together specify the file, directory or registry key to be given permission to. Lock Object contains the name of the file, directory or the registry name. Table column can be filled with File, Create Folder or Registry. Lock Object is the foreign key to the primary key of Table mentioned by Table column.Domain as I have mentioned earlier is the domain of the user.
User too as I have mentioned earlier is the User to whom we want to give the permission.
Permission is the Generic number to the permissions we have specified.
Every file, registry key, or directory that is listed in the LockPermissions Table receives an explicit security descriptor, whether it replaces an existing object or not. The Windows Installer attempts to preserve the security on objects that already exist on the system. If an object is not listed in the LockPermissions Table, and replaces an existing object, the replacement gets the security settings of the object that it replaces.
If an object is not listed in the LockPermissions Table, and does not replace an existing object, it receives no explicit security descriptor. The access to the new object is based on the attributes of its parent or container object. If an object is not listed in the table, and replaces an object with no explicit security descriptor, the access to the new object is based on the attributes of its parent or container object.
Hope this article helps you to builds up your knowledge on how to give permissions to your files, folders and registries.
