Cannot overwrite files in ProgramData\myApp installed by MSI

Question

I am about to create a MSI package. During the installation (launched e.g. via double-click on the MSI) some files contained in the MSI are deposited deeper under c:\ProgramData (resp. the CommonAppDataFolder), e.g. c:\ProgramData\myCompany\myApplication. Later when the installed application is run by the user the application may need to modify these file. The problem is that neither the running application nor the user e.g. via Windows Explorer has the right to modify any files under c:\ProgramData\myCompany\myApplication created during installation. The files do not have a readonly attribute set.

The strange thing for me now is: If I install the MSI via msiexec /q /i then I have write permissions on these files.

My MSI is created with WiX, my os is Win 7, the user is member of the administrator group.

Can anyone tell me why that is so, and how I can gain write permissions to these files w/o having to use /q /i?

Thanks Jan

EDIT 2014-03-24: Damned. I missed to specify the InstallPrivileges attribute on my element, I just didn't know about it. Setting it to "limited" does not show up a UAC prompt when installing to ProgramData! And now the user / my application is allowed to overwrite files in the destination folder :)

Are you delivering a service file? Are you moving files during the installation? Is this done via a custom action? — Stein Åsmul, Mar 20 '14 at 21:48
Tell you what, you should be able to solve this by having your application (not the setup) copy these files into the right place in CommonAppDataFolder. This would bypass all impersonations and should work ok even for limited users - or so I think. — Stein Åsmul, Mar 20 '14 at 22:12

score 1 · Answer 1 · answered Mar 20 '14 at 15:32

1

I don't know why that behavior would be different regarding access to that folder unless you have a custom action that does something that is only in the UI sequence. That's the only functional difference I can think of - the UI sequence is suppressed in a silent install.

However the common app data folder is not normally writeable to limited users. I'm not sure how much you know about UAC, but it doesn't matter if the user running the program is an admin or not because by default admins run with limited privileges. If the app needs admin privilege to run then it needs building with an elevation manifest so it asks for elevation to admin privilege. Either that or run it as administrator from a shortcut.

answered Mar 20 '14 at 15:32

PhilDW

20,260
1
18
28

I know little about UAC, but if this causes the administrator to impersonate a limited user when running an MSI, then weird stuff would happen if you run a custom action, wouldn't it? When running silently it is LocalSystem running the custom action, and it works ok? I know too little about UAC to understand this. – Stein Åsmul Mar 20 '14 at 22:09
When custom actions run from an MSI with impersonation they run as limited user. Running without impersonation is required to run elevated code, and that uses the localsystem account. A common solution is to start the MSI from an elevated launch program, then impersonated CAs will run elevated. Silent doesn't make a difference. – PhilDW Mar 21 '14 at 16:23
This doesn't quite make sense to me, I guess I have to read up on UAC. I don't have the tools installed to test with. I will ask one of the Wix guys if they are doing something special with UAC. – Stein Åsmul Mar 21 '14 at 23:09
Damned. I missed to specify the **InstallPrivileges** attribute on my element. It is not mentioned in the tramontana tutorial and I didn't examine carefully enough the xsd to stumble upon it. So, setting it to "limited" does no longer show up a UAC when installing to ProgramData. And now the user / my application is allowed to overwrite files in the destination folder :) Sorry for the wrong track... – Ed O Neill Mar 24 '14 at 12:43

score 0 · Answer 2 · edited May 23 '17 at 11:57

Windows access control is extremely complicated to deal with. In every version of Windows there is something new and changed to deal with, and it looks like the default write access in ProgramData now includes some sort of special ACL / DACL. If this is indeed the problem you can apply new permissions there and open up for regular users to write. Please note that I am not quite aware of exactly what newer versions of Windows apply as default. The tool I generally use to set permissioning is subinacl.exe. A real handful of a tool with a command line that can scare the most experienced system administrators. Some command line samples are here. You can also use the LockPermissions table in MSI, but somehow there are some issues with how these permissions are applied to the file system object. subinacl.exe is more complex, and more capable.

Cannot overwrite files in ProgramData\myApp installed by MSI

2 Answers2