2

I'm working on a Desktop application, and to allow frequent updates without too much hassle, I want to install a simple "bootstrap" application to the "Program Files" directory, and the actual application to "C:\ProgramData". This would allow me to automatically update the application without administrative access, since ProgramData is writable by all users.

This application will only be used in corporate IT environments that have an agreement with my company. Most of these environments have users running as non-admins, which has limited our ability to update our software, as we have to coordinate with the IT departments to roll out an upgrade.

Are there any problems with this approach that may not be obvious? I'm wondering around permissions, common corporate policies, antivirus, etc.

marstato
  • 4,538
  • 2
  • 15
  • 30
Brandon
  • 5,873
  • 6
  • 37
  • 59
  • 1
    What are you trying to protect and from whom? Why do these users not have admin rights? What new rights are being granted using this scheme? – candied_orange Apr 13 '17 at 00:10
  • I think you misunderstood, my application is used in corporate environments so I have no control over their IT policies. If they don't grant users admin privileges, I can't change that, so I need another solution. – Brandon Apr 13 '17 at 00:37
  • 4
    Can't the IT department simply push out the updates through the normal mechanisms? Or is there a reason normal users would need to update themselves independently? – cbojar Apr 13 '17 at 01:37
  • 3
    http://stackoverflow.com/q/12049469 – Robert Harvey Apr 13 '17 at 01:46
  • 4
    My expectation is that when you talk to those IT departments of your customers that they want to be in control when which updates are rolled out. – Bart van Ingen Schenau Apr 13 '17 at 06:19
  • 3
    What about a Group Policy which requires executables to be started from `Program Files` (or its x86 equivalent) folder? Then you're lost with that trick. – Bernhard Hiller Apr 13 '17 at 07:31
  • 1
    The IT departments we're working with often don't have the resources or systems in place to facilitate software updates, so we're left with unpatched software for years until IT is willing to manually update thousands of locations. This is the primary use case. Our updater would be automatic and require no user interaction, but updates would be approved by IT first (contractually required). – Brandon Apr 13 '17 at 09:40
  • I can understand not having the infrastructure in place if you have fewer than a couple dozen, but for thousands of locations that's absurd. – whatsisname Apr 14 '17 at 16:30

3 Answers3

5

Presumably these companies have "locked down" their user desktops for [what they consider to be] Good Reasons. By implementing a mechanism that circumvents their Policy, you are opening up a whole can of legal worms.

Talk to these IT departments about how they manage application deployment and work with them. Don't try to "work around" them.

You are a Developer writing an application. You care about delivering shiny, new features.

They are Companies that uses your application (among others). They care about having software that works so that they can run their business.

Also, by working with these IT departments, you intrinsically gain a whole bunch of [unpaid] Testers, because they will [probably] want to trial any new versions of your software and may well find defects for you.

Phill W.
  • 11,891
  • 4
  • 21
  • 36
  • I'm not trying to work around them, I'm trying to help them. I'm not some rogue cowboy, my company has contracts with their company. They have to approve any updates, but most of them lack the infrastructure to push out software updates. That said, they want us to still be able to provide software updates. – Brandon Apr 13 '17 at 10:45
  • So they've taken away their users' ability to install their own software but have provided no viable alternative for distributing "authorised" software? Seems a trifle short-sighted on their part, to me. The common approach used by most "big" companies is to install an "updater" Service on each machine and then allow *that* to ["download" new files and] install them. By default, all Window Services run in an "elevated" security context and can do [pretty much] what they like. – Phill W. Apr 13 '17 at 10:54
  • @phillw short sited, maybe, but depressingly common in medium sized enterprises, in my experience. They don't give users admin for a variety of reasons (from malware prevention to the potential legal issues when users start installing pirated software) but don't tend to have anyone experienced enough to set up a good alternative solution, because IT staff that know how to do that cost more money than a company with say 10-20 desktops can justify. – Jules Apr 14 '17 at 16:58
2

Based on the description of your goal (rather than the attempted solution of trying to write into the C:\ProgramData folder), I'd suggest looking in to Microsoft ClickOnce Deployment.

ClickOnce is most commonly associated with .NET Applications developed using Visual Studio, however ClickOnce as a deployment tool will work for any application, regardless of the tools and technologies used to build it.

If you've got a .NET App, then ClickOnce is a no-brainer. For any other app, or a Visual C++ app you can achieve the same goal with a tool called Mage.

(Note: With ClickOnce, there should be no need for you to develop your own bootstrap application or updater; this is all part of the package)

Update - credit to @RubberDuck:

There is a caveat to Click Once, you have to design your application so that it doesn't have to do things that require admin privileges on installation. For example, forget Click Once if you need to do any COM registration. There's a benefit you didn't mention as well. Updates can be controlled from a central location if you use the auto-update feature.

Ben Cottrell
  • 11,656
  • 4
  • 30
  • 41
  • 1
    I came here to give the same answer. There is a caveat to Click Once, you have to design your application so that it doesn't have to do things that require admin privileges on installation. For example, forget Click Once if you need to do any COM registration. There's a benefit you didn't mention as well. Updates can be controlled from a central location if you use the auto-update feature. – RubberDuck Apr 14 '17 at 10:41
-1

Your question is operating system specific and makes no sense on Linux or MacOSX.

Technically, a possible way to code your application is to have most of it be a plug-in (i.e. some DLL; but beware of the DLL hell); the executable proper would be just a small stub (hopefully a fixed one) doing calls to LoadLibrary or similar dynamic loading (or linking) functions.

You could also consider embedding some interpreter (e.g. Lua or Guile) in your application (and let your user update the bytecode or script for it). Or even use some JIT compilation library (à la asmjit or libgccjit or LLVM or libjit).

In some abstract way, code is data and data is code. Read about Turing-completeness and accidentally Turing-complete systems, and remember that the Halting Problem is unsolvable.

In all cases, I am not sure it would be a wise idea, as commented, the IT departments of your clients might be unhappy about it.

(I feel you are looking for a technical solution to what is actually a social issue: the trust that IT departments put on external software)

You would need to convince your customer that (whatever mechanism you will use) your "solution" is not an additional door for virus or malware (specifically written for your application).

Read about trusted computing base and proof-carrying code and dynamic software updating. Beware of (unwanted) code injection.

Read again Thompson's Turing Award Lecture Reflections on Trusting Trust (1984) it is still actual and very relevant to your concerns.

PS. I don't know and don't use Windows, but only Linux.

Basile Starynkevitch
  • 32,434
  • 6
  • 84
  • 125