Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Win32 interop fails when user changed to root (su, sudo, login) #4465

cerebrate opened this issue Sep 4, 2019 · 3 comments


Copy link

commented Sep 4, 2019

  • Your Windows build number: Microsoft Windows [Version 10.0.18970.1005]

  • What you're doing and what's happening:

Win32 interop fails when run after changing user to root (i.e, through sudo, su, login, etc.):

avatar@athena-wsl:~$ sudo /mnt/c/Windows/notepad.exe
Segmentation fault

(Interestingly, this does not occur when you change to another non-root user --

avatar@athena-wsl:~$ su foo
$ /mnt/c/Windows/notepad.exe
# notepad spawned successfully!

Unless you have first changed to the root user - i.e., becoming non-root again doesn't help:

avatar@athena-wsl:~$ sudo -s
athena-wsl# su foo
$ /mnt/c/Windows/notepad.exe
Segmentation fault 

However, if the distro is entered (be it stopped or already running with another user) as root, i.e., using the wsl -u root command, interop works properly as uid 0.


  • What's wrong / what should be happening instead:

Notepad should be launched, as it is if /mnt/c/Windows/notepad.exe is executed without sudo, su, login, etc.

I've attached an strace, but since strace doesn't honor the setuid bit for security reasons, I had to use the extended already-root version --

sudo strace -o launchnotepad.strace -u root -f sudo /mnt/c/Windows/notepad.exe

--which may or may not offer useful information.



This comment has been minimized.

Copy link

commented Sep 5, 2019

Very interesting, I'll give this a try.

@benhillis benhillis self-assigned this Sep 5, 2019


This comment has been minimized.

Copy link

commented Sep 9, 2019

I know this is fix-inbound now, but for anyone else having trouble with it in the meantime --

I stumbled into the solution while researching something else entirely (namely, needing to get certain environment variables, such as WSL_DISTRO_NAME, to exist inside genie sessions as well as outside). In the course of so doing, I happened to note the existence of the WSL_INTEROP environment variable, and aha, I thought to myself, it so happens that sudo(1) and other similar utilities drop the environment for security's sake.

One quick experiment with sudo -E later, and I note that preserving the environment, or simply recreating the WSL_INTEROP environment variable on the other side, makes interop-as-root work just fine.


This comment has been minimized.

Copy link

commented Sep 9, 2019

WSL_INTEROP is very unstable. It expands to the unix socket path (file $WSL_INTEROP) that /init uses to communicate between their forked ones (e.g. pid 8 and 9).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.