1 reply to this topic

[aarthi_m]

During install i set the following pemissions to a file -
Administrators - full control
SYSTEM - Deny Write
Users - Deny All rights
Power Users - Deny all rights
Terminal Server user - Deny all rights

I set these permissions in a custom action using Windows API to set Access Control Lists (ACL). Install succeeds and the file permissions are set.

Uninstall gives an error 1321 - user does have sufficient privileges to modify file. The error has the name of the file whose permission was set during install. This error comes from InstallValidate action.

Why does this happen? Does 'msiexec' run as SYSTEM? As SYSTEM does not have write access, does installvalidate fail?

However, if i change the permissions for Users, ie. deny only write instead of all permissions and retain the SYSTEM permissions, uninstall succeeds.

Can someone help me understand this.

[Glytzhkof]

msiexec runs two processes, one client and one server process. The client process runs in the context of the user that launched the setup, the server process generally runs as LocalSystem (at least in deferred mode) - this is all complicated under the hood, the statement above is an oversimplification. Depending on how you have scheduled your custom action and in what mode it runs (deferred / immediat), the results could be different.

Other than that, I would strongly recommend AGAINST doing this kind of permission tweaks. Remember that if your setup ever will be deployed by a large company they will have a deployment system in place, and the install and uninstall will likely be made by special accounts such as smsuser, novelluser etc... Permissioning done by the MSI in such cases will generally cause XFiles-style deployment problems.

One thing to really stay away from is messing with the file ownership as I have seen this make even admin launched setups fall over on uninstall.

Also: there is absolutely no good reason that I can think of to lock down the SYSTEM account's access to anything on the computer.