[BUG] MSIX cannot install per-user service

[christopher-rtf]

Project MSIX SDK

Describe the bug With the advent of Windows 10, Microsoft introduced per-user Windows Services. These services are started when a user logs in, run with the user's permissions, and are automatically shut down when the user signs off.

These new user services also alleviate some of the security restrictions put in place for Windows Services with newer releases of Windows (since they are effectively background user processes).

To Reproduce Create an MSIX project (using the MSIX Packaging Tool, using manifest schema, or otherwise).

Under StartAccount (from the manifest's desktop6:Service XML entry), there is no option for per-user services. The only options are "localSystem", "localService", and "networkService"--all of which are system service options. See: https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop6-service

Expected behavior I expected to be able to specify "userService", possibly also requiring a share/own process option (since the SERVICE_USER_SERVICE (0x40) flag is OR'd with similar flags in a traditional Windows Installer context).

Screenshots n/a

Platform Windows 10 and Windows 11

Additional context To follow best security practices and to enable services to seamlessly use the current user's security context, some services should be run as per-user services rather than under system accounts. Many of Windows 11's services can do this.

We can do this with MSI. But it would be really great if we could move forward and use the latest packaging technology and all of the benefits it provides--both in Enterprise environments and also for consumers (with simple right-click app removal, etc.).

Some notes from Microsoft on per-user services: https://learn.microsoft.com/en-us/windows/application-management/per-user-services-in-windows

A useful post with some background info on installing per-user services: https://helgeklein.com/blog/per-user-services-in-windows-info-and-configuration/

[jvecc]

I dug a little bit more on that topic. If we update the proper registry keys of the service, then we can see it will be installed as a per-user service. But unfortunately, when it tries to reach the executable under "C:\Program Files\WindowsApps", it is not authorized to do so and crashes.

Is there be anyway to make some progress on this topic?

[DrusTheAxe]

NOTE: This isn't a bug, it's an enhancement request. MSIX today supports per-machine Services and doesn't support per-user Services.

I dug a little bit more on that topic. If we update the proper registry keys of the service, then we can see it will be installed as a per-user service. But unfortunately, when it tries to reach the executable under "C:\Program Files\WindowsApps", it is not authorized to do so and crashes.

Interesting but insufficient. Even if the pkgdir's ACLs were updated you'd still run afoul of the Deployment stack's notion of how to service a Service. That only understands per-machine semantics; that won't work per-user.

Is there be anyway to make some progress on this topic?

Please create an Issue for the enhancement request to support per-user Services. That gets it onto our radar for planning consideration.

This almost certainly requires changes to Windows, though WinAppSDK may also be part of the solution. Similar to how the windows.dataShortcut extension was implemented in WinAppSDK 1.1.

[mikehearn]

@DrusTheAxe a couple of questions if you have the time.

1. Is there an explanation anywhere of the WindowsApps ACLs in depth, what exactly they do and why? You reference updating them here as if that's a normal thing to do but it seems that changing the ACLs is a common source of people breaking their own machines in unexpected ways.

The reason I ask is, we help people make MSIX packages for their apps, and sometimes they hit unexpected problems whereby attempting to run an EXE inside a WindowsApp directory fails with permissions errors, either from outside the package or sometimes inside it, and it's not at all obvious why or what the purpose of this permissions check actually is. I can imagine that listing the contents of c:\Program Files\WindowsApps is denied for privacy reasons (to stop apps finding out what other apps you have installed?) and the reason why you can't write to your app dir is obvious, but it seems to go beyond that and operations you'd expect to work fine can nonetheless fail. When this happens it's unclear if there's a problem or if it's expected/desired that this part of the filesystem behaves differently (more awkwardly) than normal.

2. You mention MSIX being patched via the "WinAppSDK". The page you link to implies that MSIX is now being upgraded outside of Windows Update cycles. Is there more information about this? If you're shipping a Win32 app inside an MSIX, how does one get these updates onto users systems and are there any catches (e.g. win10 not being supported)?