Let cbwin in session mode launch multiple wcmd instances in parallel

[fpqc]

Hi @xilun I was thinking about cbwin and Alex Ionescu's lxserver/lxext persistent communication socket idea, and I was thinking, you could likely do it even more easily with cbwin in session mode.

So here's the idea: when you run something like wcmd cmd or wcmd powershell when cbwin is in session mode, you have two options:

wcmd could inform outbash.exe that it's going to poll a new tcp port, and then outbash launches a new cmd.exe instance that is broadcasting over that new port, just like if we launched a new instance of outbash. If wcmd gets killed, outbash should kill the cmd that it launched.

The other option is to avoid negotiating a secondary tcp port at all, and tag communications between instances of wcmd and outbash on the session port with the PID of the wcmd instance.

The idea behind this is that you could run a single outbash session but lots and lots of wcmd instances in parallel, so for instance, you could run several copies of cmd.exe, powershell.exe, zsh, bash, etc inside of a terminal multiplexer like tmux, or in separate terminal emulators running within the same lxsession.

The benefit of the second method (tagging) is that if/when MS documents the interface that Alex Ionescu's lxserver/lxext uses, you could immediately remove the tcp loopback and pipe communications directly.

[xilun]

You can already launch as many wcmd in parallel as you want, regardless of if you used --outbash-session or not. A new cmd.exe is launched for each wcmd call (or each wstart call, for a short time).

[fpqc]

Oh, wow, that's great!

[xilun]

That's actually more simple than trying to use a single cmd.exe, but there are drawbacks too (you can't modify the Win32 environment in a persistent way with cmd set VAR=x commands)

[xilun]

(Anecdotally, when I validated the security design based on GetExtendedTcpTable, I launched > 1000 cmd.exe and other processes in parallel.)

[fpqc]

Sorry, @xilun so why isn't --outbash-session mode the default? That's amazing!

[xilun]

--outbash-session just also writes the port to ~/.config/cbwin/outbash_port

Launching multiple processes in parallel works whether or not this option is activated.

To be more precise launching stuff works like that:

(I will still simplify a bit because there are also nasty details about how Win32 processes are handled in Windows Job objects, etc.)

• the client connects to outbash.exe in TCP on 127.0.0.1 using the port (from the env var or ~/.config/cbwin/outbash_port)
• outbash.exe spawns a new thread to handle the new connection. We are targeting 64-bits only so the limit for the number of simultaneous connections is basically related to the amount of RAM you have... (EDIT: and TCP ports, but that's ~ 65000)
• outbash.exe connection thread retrieves the Win32 PID of the client process with GetExtendedTcpTable, then validates the client is running as the same Windows user as outbash.exe is, and with UAC elevation if needed (more precisely with at least the same "mandatory integrity level") - if access is not granted the connection is closed by outbash.exe before it reads a single byte from the client.
• the client sends the command to execute and related info (win32 working directory to use, win32 environment variables to override, wanted stdin/stdout/stderr redirections, ...)
• if the client requested redirections, it also starts to listen on one new TCP port per stream
• outbash.exe connects to each redirection socket using the client ports if needed, then uses CreateProcess with options corresponding to what the client requested (if redirections are wanted, they are directly done to the win32 side of the sockets thanks to some CreateProcess options)
• the client creates one thread per redirection to forward the data to the corresponding WSL file descriptor (initially I was doing it with only one thread, but it's actually not possible to do that without a bug because of how shitty is Posix about non-blocking IO)
• if CreateProcess succeeds, outbash.exe connection thread just wait on the created process termination or further commands from the client, or failure of the controlling socket from the client. For now the only commands that exist at this stage are "suspend" and "resume", to propagate the effect of Ctrl-Z.
• on termination outbash.exe connection thread sends the win32 process exit code to the client. The client exits with the same code (if in range)

[xilun]

And now that I wrote this and read it again I see a security issue I did not thought about before, but it's not ultra critical.

[xilun]

@fpqc thank you for making me discover that security risk :P

[xilun]

@fpqc what does fpqc means? My fingers often type fqpc (not that it would mean much more for me)

[fpqc]

fidelement plate et quasi-compacte. c'est une type de schema en la geometrie algebrique

[xilun]

Ok that seems crazy as hell. I shall study math until I understand that :)