fix askpass named pipe name path prefix #402
Conversation
|
the CI test failure appears unrelated to the changes I have made |
awakecoding
force-pushed
the
askpass-named-pipe-fix
branch
from
ac06afa to
ea3b717
Compare
|
@gerardog it looks like there's a permission issue for some of the GitHub Actions? I wonder if it's caused by who triggers the CI
I really need this fix |
|
Hi Marc. I hadn't realized that the builds were failing. I thought you had a signed CI build available already. Sorry for the delay. You can fetch signed binaries with version Thanks for the collaboration! |
|
Sorry, the previous build was unsigned, try this one. |
|
Hi @gerardog , using the new build I'm getting stuck trying to launch powershell after entering the password. Is there a known issue? 2.6.0 (working): 2.6.1 (not working): |
|
Hi @JDelSignore. 2.6.1 is same as 2.6.0 except for @awakecoding fix. 2.6.1 is not commonly downloaded, as it is a preview build with no users. So it's possible that your antivirus software treats it differently, for example show a popup. Are you invoking gsudo from a Windows Powershell instance in both screenshots? I can't tell from the above screenshot if the shell you are calling from is Powershell v5.1 or Pwsh v7.4. Can you try |
|
@gerardog Sorry didn't realise I cropped the first screenshot, yes both times I ran Windows Powershell 7.4. Here are the results for 2.6.0 vs 2.6.1 with debug enabled: 2.6.0 2.6.1 |
|
And from the gsudo console: 2.6.0 2.6.1 |
|
@gerardog Turns out that it works fine on a VM, so it must be Sophos that blocks it on my host like you said. Pretty safe to say it's OK to release. |
|
@gerardog don't hold the release for the suspected Sophos issue, but I did spend some time trying to figure out why it hangs, and the plot thickens. Sophos-related DLLs do get loaded into gsudo.exe, but I confirmed with IT and it's not getting blocked - so whatever happens, it's probably not intentional interference. I built the exact same version locally and it runs just fine - release, unsigned. I removed the signature from your preview build, but it didn't change anything. I've done a bit of procmon to see if I could identify a difference in behavior: I launched gsudo.exe from cmd.exe to more easily filter on pwsh.exe without background noise from unrelated pwsh.exe instances. Here's a local build that works, launched with --debug. I can see a first gsudo.exe terminal pop for a second to be replaced by a second one, and the original command prompt correctly gets attached to a pwsh.exe process:
In procexp, we can see the full chain of processes for the "happy path" scenario:
Here's your prebuilt gsudo.exe launched in the same way, it somehow gets stuck on the first gsudo.exe terminal, and I confirmed in procmon that pwsh.exe is never launched (and apparently isn't even attempted to be launched, no file operations on pwsh.exe show up in procmon):
Here's the chain of processes for the "sad path" scenario:
I get the feeling that this is a one-off weird thing that happened just for that one preview build you did, and I'm crossing fingers a new build would work just like the 2.6.0 release build does. Does this give you a hint about a possible root cause for the problem? |
|
Hi @gerardog Do you have an ETA for when 2.6.1 will be released with this fix? |
3 participants
In my original pull request (#388) adding support for the GSUDO_ASKPASS_NAMED_PIPE environment variable, I made a minor mistake: the named pipe name should not include the \.\pipe\ path prefix.
Here is how to properly test this feature:
Save this to an AskpassNamedPipeServer.ps1 file:
Open a PowerShell terminal, and launch the script:
In another terminal, launch gsudo.exe with the
-uparameter for a valid user, setting the GSUDO_ASKPASS_NAMED_PIPE environment variable to point to your named pipe:If everything worked, you should see the named pipe server printing out that it "served" the password and closed. gsudo checks if the user exists first, so it will only try to read from the named pipe if the user exists.