Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Coapp engine engine as a service redesign
The problem, is that when the user double-clicks on an a CoApp MSI, Windows Installer elevates the installer process by switching to the LOCALSYSTEM (NT AUTHORITY\SYSTEM) account, but actively removes a bunch of privileges that they didn’t figure an installer would need—specifically the ability to create symlinks has been removed. Symlinks are a critical part of CoApp’s design, and I’m not willing to compromise the features thatrely on them.
The only way we can get from that crippled LOCALSYSTEM account to a real LOCALSYSTEM account is to create a Win32 service, and spin it up (which we can actually do from that crippled LOCALSYSTEM account), and have it do the work we need done.
Options: Cheat -- build small service that we install as localsystem to do that small bit of dirty work Change -- so we don't use that. ggrrrr.. Not without sacrificing important features Fix CoApp Engine -- split the engine into two parts: - Engine "Service" which handles all the high-privilige work - Engine "Client" which runs as the regular user, handles networking and files
- Reduce the size of the Service engine to a minimum; - Do a full security audit on the Service engine. - create a communications interface to the Service that the client can talk to. - have the Client engine talk to the Service over the interface - the engine "client" handles all the networking and off-box communication, so we don't have to have painful workarounds for proxies and local network resources
Actual Good Points:
- Lets us create symlinks from an MSI install. - Limits further the actual amount of code running at an elevated level. - Moves all the network communication into userspace where - we can arbitrarily decide what features "require" the user to be elevated (so, updates can happen without user elevation)
* Core Toolkit -- Common code shared amongst all components * Engine Service -- Win32 service that handles high-privilige operations, core logic. + Client Toolkit -- Common code shared amongst low-privilige apps - Handles all off-box communications(SMB/http/https) + Engine Client -- Code to talk to Engine, low-privilege operations + Client Apps -- (Tray App, Mini-Installer, Command Line , GUI Package Manager) + Bootstrapper -- Runs as crippled LocalSystem, installs the service components.
- Communication Channel between userspace and the Engine Service? - how do we handle asynchronous requests/responses? - multiple clients connecting concurrently? - remote management in the future? - make technology agnostic? (no .NET-only features?) - How much stuff in the Engine Service - Where do we draw the line for what "requires" user elevation? - Who will participate in security audits? - Other help (gui/clients)?