Monday, November 24, 2008

Different Ways of Giving Permissions in Your Windows Installer

Windows XP/Windows 7 works under a locked down environment in most organisations. The MSI authors generally have to provide permissions to the installation directory, so that the users without admin rights are able to access and write data into the installation directory.
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:



  • Full Control


  • Modify


  • Read & Execute


  • List Folder Contents


  • Read


  • Write

  • 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:



  • view file name and subfolders


  • navigate to subfolders


  • view data in the folder's files


  • add files and subfolders to the folder


  • change the folder's files


  • delete the folder and its files


  • change permissions


  • take ownership of the folder and its files

  • Modify - Permits the user(s) to:


  • view the file names and subfolders


  • navigate to subfolders


  • view data in the folder's files


  • add files and subfolders to the folder


  • change the folder's files


  • delete the folder and its files

  • Read & Execute - Permits the user(s) to:


  • view file names and subfolder names


  • navigate to subfolders


  • view data in the folder's files


  • add files and subfolders to the folder

  • List Folder Contents - Permits the user(s) to:


  • view folders


  • navigate to subfolders


  • view folders


  • does not permit access to the folder's files

  • Read - Permits the user(s) to:


  • view the file names and subfolder names


  • navigate to subfolders


  • run applications


  • open files


  • copy and view data in the folder's files

  • Write - The Read permissions, plus permits the user(s) to:


  • create folders


  • add new files


  • open and change files


  • delete files


  • You can set permission to folders in following ways:


  • Secedit


  • XCACLS/ICACLS


  • LockPermission table.

  • Full Control - Permits the user(s) to:


  • view file name and subfolders


  • navigate to subfolders


  • view data in the folder's files


  • add files and subfolders to the folder


  • change the folder's files


  • delete the folder and its files


  • change permissions


  • take ownership of the folder and its files

  • Modify - Permits the user(s) to:


  • view the file names and subfolders


  • navigate to subfolders


  • view data in the folder's files


  • add files and subfolders to the folder


  • change the folder's files


  • delete the folder and its files

  • Read & Execute - Permits the user(s) to:


  • view file names and subfolder names


  • navigate to subfolders


  • view data in the folder's files


  • add files and subfolders to the folder

  • List Folder Contents - Permits the user(s) to:


  • view folders


  • navigate to subfolders


  • view folders


  • does not permit access to the folder's files

  • Read - Permits the user(s) to:


  • view the file names and subfolder names


  • navigate to subfolders


  • run applications


  • open files


  • copy and view data in the folder's files

  • Write - The Read permissions, plus permits the user(s) to:


  • create folders


  • add new files


  • open and change files


  • delete files

  • You can set permission to folders in following ways:


  • Secedit


  • XCACLS/ICACLS


  • LockPermission table.

  • 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.


  • Give Custom Action name as per your standards


  • Working Directory to be set is Templates folder (where we have placed the .inf file.


  • In exe and Command line give the following command:
    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.



  • The location of the Custom action should be just before install finalize.


  • The Condition for launch of Custom Action should be "NOT REMOVE"


  • The Custom action can be run in deferred mode in system context.

  • 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.

    Tuesday, November 18, 2008

    Required Properties in MSI

    There are five properties which are required by every Microsoft installer to identify itself from other MSI.

    These properties are required to be present in every MSI.

    These are the five properties:

    1) Product Name: It is the name of the application you mention in your MSI.
    2) Product version: This is the version of the product which you give.. like 1.0.0 etc..
    3) Product code: It is the unique GUID for your MSI.
    4) Product language: This is the numeric value of product and should be one of those entries mentioned in Template summary property in Summary information stream.
    5) Manufacturer: This is the name of the manufacturer of the product.
    For future upgrades, it is recommended to add Upgrade code property in the package.