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

Closed
cerebrate opened this issue Sep 4, 2019 · 4 comments

Comments

@cerebrate
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
Password:
$ /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.

launchnotepad.strace.txt

@benhillis

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

Very interesting, I'll give this a try.

@benhillis benhillis self-assigned this Sep 5, 2019
@cerebrate

This comment has been minimized.

Copy link
Author

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.

@Biswa96

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).

@benhillis

This comment has been minimized.

Copy link
Member

commented Sep 24, 2019

Fixed in 18990

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