Wednesday, June 8, 2011

MSI, Orca and file permissions: or it's 2011 and installers still suck

I had to create an MSI for distributing some software. After installing, I noticed that one of the files didn't allow read/write permissions to my application. You'd think that would be easy to fix: just go into Visual Studio, select the file and change the security permissions, right? Wrong.

If you have the same problem, one way to resolve it is:
  1. Download Orca (it allows you to edit MSI files)
  2. Run Orca and open an MSI file
  3. Go to the LockPermissions table
  4. Add a new row and fill in four of the five fields (see image). The fields are:
    1. LockObject (the ID of the file, this is found in the File table);
    2. Table (the name of the table that you're editing, in this case the "File" table, but it could be "Registry" or something else);
    3. Domain (I left this bank);
    4. User (I put in "Everyone" which is incredible insecure, but I really don't care);
    5. Permission (the meaning of the numbers is explained here);
  5. Save the MSI and exit Orca

Usually, installed files take on the permissions of the directory they are installed to. If you install to "C:\Program Files," your files will get the permissions that the program files directory has. However, using LockPermissions will overwrite all of these permissions and just assign SYSTEM and the permissions you added in the LockPermissions table. This is super-dodgy, but then, the whole thing is super-dodgy. Other people recommend using a custom action as part of the installation, e.g., using "ICacls". This is probably a better way to do it, I was just running out of time.

1 comment:

  1. How can i set this read write permission to a folder which is created in programdata folder?