x/sys/windows/svc : IsWindowsService doesn't work properly inside a windows container

[gillg]

What version of Go are you using (go version)?

$ go version go1.19.2 linux/amd64
x/sys v0.1.0

Does this issue reproduce with the latest release?

Yes

What did you do?

If I use IsWindowsService() inside a container servercore:ltsc2019 it always returns false, nevermind if I launch it as CLI or as service.
In windows containers world the service stack is native. It's not necessarly a "container pattern" but it's widely used for multiple reasons. So that method should work.

After some tests, the fail reason seems pretty simple.
On the host the "Session ID" of the process svchost.exe (for example) is 0, but inside the container, the "Session ID" of a process svchost.exe is 1.
The only process with a session ID 0 inside a container are :

Get-Process | where {$_.SessionId -eq 0}

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
      0       0       56          8                 0   0 Idle
     50       3      456       1212       5.20    964   0 smss
   2117       0      156        136      23.61      4   0 System

But good news, the parent process is still "services.exe".

WmiApSrv is a random service (it's the native monitoring stack of windows)

Get-Process -Id (Get-CimInstance Win32_Process -Filter "Name = 'WmiApSrv.exe'" | select ParentProcessId).ParentProcessId

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    218      10     3628       7780     175.66    524   1 services

I think, removing the condition parentProcess.SessionID == 0 could be safe and fine... Any windows guru there ?

In the meantime, the older deprecated funtion IsAnInteractiveSession is also buggy in a container, and never detects an interactive session even if you are in a CLI.

[bcmills]

(CC @golang/windows)

[alexbrainman]

Thank you for creating this issue.

I think, removing the condition parentProcess.SessionID == 0 could be safe and fine...

If you look at the code, you can see that Go code is copied from Microsoft .Net code:

https://github.com/dotnet/extensions/blob/f4066026ca06984b07e90e61a6390ac38152ba93/src/Hosting/WindowsServices/src/WindowsServiceHelpers.cs#L31

And that code still checks for sessionID of 0.

Do you have any references that it is safe and fine to remove parentProcess.SessionID == 0 check?

Thank you.

Alex

[gillg]

@alexbrainman Now I asked an official question to Microsoft. But their condition is probably just a safety guard to avoid a wrong interpretation if a process is spawned from a custom process named services.exe.
So adding a condition on session name seems safer than nothing,

[gillg]

@alexbrainman I have a very good news. The answer is already done.
They decided to just remove the session Id condition (with the probable risk of a wrong result of you name your own exe "services").

So x/sys should follow the same logic I think.

Original code https://github.com/dotnet/runtime/blob/36bf84fc4a89209f4fdbc1fc201e81afd8be49b0/src/libraries/Microsoft.Extensions.Hosting.WindowsServices/src/WindowsServiceHelpers.cs#L32

[bcmills]

(That was dotnet/runtime#52416.)

[alexbrainman]

They decided to just remove the session Id condition (with the probable risk of a wrong result of you name your own exe "services").

So x/sys should follow the same logic I think.

@gillg sounds good to me.

Do you want to send a CL? See https://go.dev/doc/contribute on how to contribute.

Thank you.

Alex

[gillg]

@alexbrainman it's the weekend, so maybe I can succeed to follow the contribution guide 😆

I let you know if I don't have time or succeed to open a correct PR.

By the way do you have an internal mechanic to observe changes to their runtime and see if changes in Golang are revelant ?