Question

I’m developing a Windows application that has a silent updater, so the executable needs to be able to be overwritten.

The application also loads some .dlls

I tried putting the executable and dlls in the application data folder, but visual studio give me a warning about how the files will not be accessible to all users.

I tried putting the executable in the application data folder and the dlls in the program files folder but the application crashed because the dlls could not be loaded.

How can I either A) remove the warning or B) organize everything in a better way?

Answer 1

There is no such folder on the system. Some ideas I have are:

• Use the GAC. As far as I am aware, if you bundle your binaries as a digitally signed assembly, the GAC will allow both silent installs and “upgrades”. (Here the security is inherent in the public key being part of the assembly id, so it doesn’t matter what ends up in the GAC, as long as it’s signed, a “malware” assembly can’t impersonate a signed assembly)

• Use an MSI based installer: Again, After an initial administrative install the MSI installer will allow the silent install of patches to existing digitally signed content. Here the security is inherent in the administrator first giving permission for the install. The signed patch MSIs can be confirmed to come from the same publisher so MSI doesn’t need to re-prompt for permission).

• Install the primary binaries to a shared location with UAC elevation. Store patch binaries in a per-user folder. This prevents non administrator users overwriting each others files. There is some redundancy potentially, but so what.

• Lastly (and leastly), create your own folder, pretty much wherever you want. At creation time the software is the owner of the new folder from a windows security point of view, and, as the owner, you have implicit permission to adjust the ACL’s of the new folder. So your initial install process, run as a user or administrator, can, (on folders it can successfully create) adjust the ACL of the folder to give the “Users” group inheritable R/W access. All files subsequently created in the folder by any user would then be readable and writeable by all users (except guest (and you really DON’T want to give Guest users write access to anything).

This last option is a security issue as regular users should not be able to effect the execution environment of other users. “Users R/W access” means that regular users could install Trojans or otherwise tamper with other users data on the system, which has, in essence, elevated all users to ad hoc administrators.

• A more secure angle is, during the initial install, to install an update agent as a service. The non elevated software running on each users account would then use some kind of IPC to connect to the service, which, running as SYSTEM, would have permission to update files in locations the User account’s don’t have access to.

This is quite a complicated solution and essentially re-invents the wheel – the MSI installer uses a service agent component to perform upgrades with no UAC prompts.