[Bug]: UNIX domain sockets fail when created in VFS virtualized directories

[mikehearn]

Version

Windows 10/11

Repro Steps

1. Write a Java 20 app that tries to establish an outbound TCP socket to any arbitrary internet domain.
2. Package it with MSIX. It doesn't have to use App Isolation, just Helium is enough of an app container to trigger this.
3. Install it.
4. Run the app. Observe that it crashes with an exception.

Unexpected Results

Exception as discussed here: https://mail.openjdk.org/pipermail/nio-dev/2022-November/012525.html

Analysis:

• The Java API supports cancellation/interruption, which requires a thread that's waiting on a socket to be wake-up-able from another thread. To implement this Java opens either a loopback TCP connection or in recent versions a UNIX domain socket, so it can use e.g. WaitForMultipleObjectsEx to wake up either on TCP traffic or when another thread tries to cancel the operation, which it does by writing a single byte to the wakeup channel.
• Outside of app containers this works.
• Inside of app containers this fails in a rather inexplicable way, in which creating the UNIX domain socket in %TEMP% works but connecting to it as a client does not.
• This causes Java to fail to establish the local cancellation connection and therefore the entire outbound network connection.

De-virtualizing %TEMP% using the AppManifest.xml fixes the problem, so the bug is definitely in Windows, most likely somewhere in bindflt or the UNIX domain sockets driver. Unfortunately, whilst de-virtualizing %TEMP% does fix the issue, it then causes the Microsoft Store to throw a fit and demand explanations about why it's being done, which seems to then trigger extended reviews and pushback.

So for App Isolation to work, bugs like this need to be fixed. Also please note: bugs need to be fixed in Win10 too, because the decision to ship an app as MSIX can't really be isolated to just Win11 users. But at the moment MS is not backporting fixes to Win10 and this makes MSIX harder to use. My company makes a product that packages apps for the desktop and this is one of the bugs we automatically work around.

[tiangao-ms]

Hi @mikehearn , it seems like this is an MSIX issue? We'll send this to our colleagues and see how they would proceed with this.

[mikehearn]

@tiangao-ms It's an app container issue, I'm not sure what team is responsible for that inside MS but as this is about Win32 sandboxing I guess it's not that important which team is responsible? Someone has to fix the bugs, right? The sandbox would depend on app containers regardless of whether MSIX existed or not.

[mikehearn]

@tiangao-ms Any update on this bug?