Error: `System.InvalidOperationException: No process is associated with this object` when using gsudo with Admin by Request

[Bouska]

Issue Description

I'm trying to use gsudo on my workstation. We use something called Admin by Request that sort of replace the Windows UAV. When launching a command in a user console, I always end up with the error System.InvalidOperationException: No process is associated with this object.. Is there something that can be done about that?

PS C:\Users\martinpa> gsudo --debug winget update
Debug: Invoking Shell: PowerShell
Debug: Command Line: --debug winget update
Debug: Command to run: C:\WINDOWS\system32\cmd.exe /v:on /s /c "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -Command "winget update""
Debug: Using Console mode TokenSwitch
Debug: Caller PID: 38152
Debug: Caller SID: S-1-12-1-152722810-1243977150-3172863363-149507947
Debug: Elevating process: C:\Program Files\gsudo\2.4.2\gsudo.exe --debug gsudoelevate 38152 S-1-12-1-152722810-1243977150-3172863363-149507947 All 00:00:00
Error: System.InvalidOperationException: No process is associated with this object.
   at System.Diagnostics.Process.EnsureState(Process.State) + 0x11a
   at gsudo.Helpers.ServiceHelper.StartService(Nullable`1, Nullable`1, String, Boolean) + 0x8c8
   at gsudo.Commands.RunCommand.<RunUsingService>d__8.MoveNext() + 0x344
--- End of stack trace from previous location ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb6
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x42
   at gsudo.Commands.RunCommand.<Execute>d__6.MoveNext() + 0x362
--- End of stack trace from previous location ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb6
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x42
   at gsudo.Program.<Start>d__1.MoveNext() + 0x1d3

Debug: Command Line: --debug gsudoelevate 38152 S-1-12-1-152722810-1243977150-3172863363-149507947 All 00:00:00
gsudo v2.4.2 (Branch.tags-v2.4.2.Sha.c23b1024b4974f5d90cf82968637bdb4c8924ca7)
Copyright(c) 2019-2022 Gerardo Grignoli and GitHub contributors

Caller Pid: 7260
Running as:
  User: EU\martinpa
  Sid: S-1-12-1-152722810-1243977150-3172863363-149507947
  Is Admin: True
  Integrity Level: High (12288)

Credentials Cache:
  Mode: Explicit
  Available for this process: False
  Total active cache sessions: 0

Processes attached to the current console:
      PID      PPID Integrity  UserName                  Name
     9816     25292 High       EU\martinpa               C:\Program Files\gsudo\2.4.2\gsudo.exe (this gsudo status)

Info: Service started
Debug: Service will shutdown if idle for 00:00:10
Debug: Listening on named pipe ProtectedPrefix\Administrators\gsudo_A7B36D662A84FD56CD119AD958C6ECF4FF3AF3E319D0347E69019DA8F83294C0.
Debug: Access allowed only for ProcessID 38152 and children
Debug: NamedPipeServer listening.
Info: Service stopped
Service shutdown. This window will close in 15 seconds

Steps to Reproduce

1. Launch PowerShell in a Windows Terminal (I've also tested cmd, MinGW32 and outside a Windows Terminal)
2. Enter gsudo --debug ls
3. Get the Admin by Request "UAV" and validate it
4. See the console be filled until line "Elevating process"
5. See the gsudo service console pop up
6. See the gsudo service console close down
7. See the backtrace on the main console

Screenshots

Context:

• Windows version: Windows 10 22H2

• gsudo version: gsudo v2.4.2 (Branch.tags-v2.4.2.Sha.c23b1024b4974f5d90cf82968637bdb4c8924ca7) (installed with winget)

[gerardog]

Hi @Bouska,

This is a bug on AdminByRequest, not gsudo. They are intercepting Start-Process -verb RunAs but not returning the elevated process handle.
Btw, arent gsudo and AdminByRequest incompatible per definition? AdminByRequest belongs to regulated environments and wants to intercept and log all elevations, while gsudo cache is an alternate way to grant them. Let me know if a SysAdmin officially wants to make them work together.
Anyway AdminByRequest technical support never answered my messages. I don't own a license so they are ghosting me. You may have better luck than I.

IDk if this issue is exactly the same or similar to #141, but the bottom line is, ABR api interception is not clean.

[Bouska]

Hi @gerardog

Thanks for checking this issue. I suspected the issue came from AdminRequest, guess I'll do without using gsudo. I'm closing the issue.