bash $PATH includes native Windows path entries

[markgross]

• A brief description
  I just noticed that there are entries in the bash PATH that include windows executibles. I'm not sure if this is a feature or a bug.

I see that my Anaconda3 (a windows python distrobution) has executibles on the bash path. I expected only linux native programs to be accessible from the ubuntu bash env.

mgross@marks-x1:$ which fetch_file.exe
/mnt/c/Program Files/Anaconda3/Scripts/fetch_file.exe
mgross@marks-x1:$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files/Anaconda3:/mnt/c/Program Files/Anaconda3/Scripts:/mnt/c/Program Files/Anaconda3/Library/bin:/mnt/c/Users/mark9/AppData/Local/Microsoft/WindowsApp

I worry that the leakage of the Windows environment into the bash will result in unexpected behaviors from time to time.

• Your Windows build number
  14986.rs_prerelease.161202-1928

• Steps / All commands required to reproduce the error from a brand new installation
  not sure if Anaconda3 needs to be installed before enabling the WSL or after (or if that matters.)

[Gabrielcarvfer]

@markgross people asked in UserVoice to be able to run Windows commands from bash, so it should be a feature. As it is appended to the PATH, it shouldn't make any difference if you have python or any other linux programs installed on WSL. If you don't want that to happen, just export PATH containing only WSL folders on ~/.bashrc . :)

[MikeGitb]

@Gabrielcarvfer: It makes a difference if you have installed a tool in Windows but not in linux. Usually you'd get an error like "tool XY is currently not installed. Type sudo apt install ... to install it now". If the windows version gets picked up instead, everything works either as expected or you might get very strange errors.
However, I'd expect this to be a rather rare occasion.

[markgross]

Default options should be secure options. If someone wants to add power shell env path's to their bash env they can so. But, adding things by default is IMO a problem that will bite people in the future.

Also, I don't want any python scripts or executable leaking between my windows and linux environments.

[Gabrielcarvfer]

@MikeGitb and @markgross , a switch for that in Settings's Developer section for that (injecting Windows path on WSL path) would solve your problem, but this is a work in progress, in a prerelease build, then you can use the workaround until they fix it.

[aseering]

@markgross -- to answer your implied initial question, this is a deliberate feature.

Regarding your concern about namespace collisions -- note that Windows executables must have a file extension such as .exe, .com, etc. As you've seen above, you can find fetch_file.exe, but you must then execute it as fetch_file.exe, not fetch_file. In contrast, by convention Linux executables in $PATH typically do not have file extensions. As a result, names will tend to not conflict too often. You are, of course, absolutely correct that they can conflict.

Regarding security -- my expectation right now as a user is that any malicious WSL process can acquire Linux root at any time. If you've already got root, messing with stuff in $PATH is small potatoes :-) WSL processes (even ones running as root) are all just unprivileged (as far as Windows is concerned) programs running under your Windows user account. So the environment is effectively single-user, and should IMO be secured accordingly. (The WSL team is probably looking into more-sophisticated security models, but that's what exists today, as far as I can tell.)

Regarding controlling this behavior, take a look at #1493 .

[itomkins]

On my system the bash path is truncated for some reason I can't figure:
$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/ProgramData/Oracle/Java/javapath_target_4529046:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem <SNIP> :/mnt/c/Program Files/Oracle/VirtualBox:/mnt/c/Program Files (x86)/Nma

Where the original Windows path ends with ;C:\Program Files (x86)\Nmap

Also for some reason the .profile is not adding my ~/bin directory to the path, I have copied the relevant code to the end of .bashrc and it works fine so not sure what is going on there

[benhillis]

I agree with @aseering. Since you have also provide the file extension to invoke the Windows binaries I think it is pretty unlikely that there will be much confusion. @markgross if you have a specific case where this is happening kindly reopen this ticket.

You can disable this feature by setting this registry key:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss]
"AppendNtPath"=dword:00000000

@itomkins - I assume you're running an older insider build? There was an off by one error that is fixed in recent builds.

[aseering]

@itomkins -- regarding .profile, that might be an instance of #816 ?

[benhillis]

@aseering - yes it is.

[itomkins]

Thanks @benhillis @aseering correct on both points, added --login to shortcut and will have to switch from slow to fast to pick up a newer build i guess.

[markgross]

I just watched some videos from https://blogs.msdn.microsoft.com/commandline/learn-about-bash-on-windows-subsystem-for-linux/

Specifically https://sec.ch9.ms/ch9/ed3c/e3560e79-4719-49dc-a7e8-607ca516ed3c/WindowSubsystemforLinuxFileSystem_high.mp4

around time stamp 22min it talks about the effects of native windows programs operating on WSL files. It results in files that can't be seen from the bash environment.

Please explain why allowing windows path's is a good idea? It looks like a train wreck given this new information.

[markgross]

Hmm, I guess there is one more video I needed to watch before posting my last comment.
https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/

Still, if I do the following I get a bad experiance:

1. from bash vim $HOME/temp.txt and add some text.
   2)close vim.
2. open gvim.exe (windows gvim install) gvim.exe $HOME/temp.txt

I can't edit the content I added and I can't save anychanges I made over top temp.txt