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

bash $PATH includes native Windows path entries #1640

Closed
markgross opened this Issue Jan 28, 2017 · 37 comments

Comments

Projects
None yet
@markgross
Copy link

markgross commented Jan 28, 2017

  • 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

This comment has been minimized.

Copy link

Gabrielcarvfer commented Jan 29, 2017

@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

This comment has been minimized.

Copy link

MikeGitb commented Jan 29, 2017

@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

This comment has been minimized.

Copy link
Author

markgross commented Jan 29, 2017

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

This comment has been minimized.

Copy link

Gabrielcarvfer commented Jan 29, 2017

@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

This comment has been minimized.

Copy link
Contributor

aseering commented Jan 30, 2017

@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

This comment has been minimized.

Copy link

itomkins commented Jan 31, 2017

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

This comment has been minimized.

Copy link
Member

benhillis commented Jan 31, 2017

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

This comment has been minimized.

Copy link
Contributor

aseering commented Jan 31, 2017

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

@benhillis

This comment has been minimized.

Copy link
Member

benhillis commented Jan 31, 2017

@aseering - yes it is.

@itomkins

This comment has been minimized.

Copy link

itomkins commented Feb 2, 2017

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

This comment has been minimized.

Copy link
Author

markgross commented Feb 11, 2017

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

This comment has been minimized.

Copy link
Author

markgross commented Feb 11, 2017

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

@aseering

This comment has been minimized.

Copy link
Contributor

aseering commented Feb 11, 2017

Hi @markgross -- have you actually tried running the command that you suggest? I think you will find that the set of things that you can't do is larger than you are saying :-)

@benhillis

This comment has been minimized.

Copy link
Member

benhillis commented Feb 11, 2017

@markgross - Due to the filesystem limitations you mention above accessing files in LxFs (anything not under /mnt/*) is not supported via interop. You won't be able to modify files in LxFs unless you do some trickery like passing the full NT path of .bashrc to gvim.exe.

I'd suggest trying out the feature and seeing how it works. I'd love to hear specific feedback about things that aren't working as you expect. As long as you're working out of one of your mounted NTFS drives you shouldn't run into issues.

As an aside: the limitation of not being able to modify files in LxFs is something we're spending a lot of time looking at for a future release. I would love to come up with a solution that gets rid of this limitation - but creating a mapping between Linux and NT security models is a complicated problem. Just ask anybody who's worked on samba :)

@markgross

This comment has been minimized.

Copy link
Author

markgross commented Feb 11, 2017

Thanks. I will think some more about the VSF/NTFS issues for content not under /mnt/[a..z].

FWIW I have not done any powershell based development so a lot of the utility for this feature is lost on me. but, I do work in linux on native Linux boxes. Yes, those mappings are not simple to deal with. they are so complex I would punt on it.

Understanding the use case after watching your interview helps. I'm still not sure its worth the native linux file inconsistencies that happen because of having this feature. ok, I don't think its worth it because of the LxFs / NTFS extended attributes (and caching) issues. but, I agree its handy when operating on NTFS files under /mnt/[a..z] somewhere and wanting to use native linux user mode tools.

FWIW I'd hide the extended path from the normally launched bash shell but enable it from powershell command line invocations of base.exe if I couldn't address the LxFs / NTFS issues enough for a good UX. But, the user needs to be aware of the file system limitations.

Thanks for the responses! I've been very impressed with the direct interaction with you developers on WLS.

@irontoby

This comment has been minimized.

Copy link

irontoby commented Sep 19, 2017

Not sure where the idea that "since you have to also provide the file extension to invoke the Windows binaries I think it is pretty unlikely that there will be much confusion" is coming from. Perhaps this helps illustrate the problem:

Me on any other Ubuntu system:

toby@localhost:~$ npm -v
The program 'npm' is currently not installed. You can install it by typing:
sudo apt install npm
toby@localhost:~$ sudo apt install npm

It's a super-helpful feature and incredibly streamlined workflow. I don't even worry about whether some CLI snippet I see online needs a tool I don't have. I just paste it and if something is missing, Bash tells me exactly how to get it.

Me using Ubuntu bash on Windows:

toby@localhost:~$ npm -v
: not foundram Files/nodejs/npm: 3: /mnt/c/Program Files/nodejs/npm:
: not foundram Files/nodejs/npm: 5: /mnt/c/Program Files/nodejs/npm:
/mnt/c/Program Files/nodejs/npm: 6: /mnt/c/Program Files/nodejs/npm: Syntax error: word unexpected (expecting "in")
toby@localhost:~$

Incredibly unhelpful, and not a very good experience for those who are used to Linux and expect the WSL environment to be more "clean". I didn't type any Windows extension anywhere for this to happen. I think the intersection of people who have node.js installed on Windows and want a completely separate node.js in WSL would be quite high.

Very glad to see the regedit entry to solve this, but exposing it more visibly would be quite welcome. At any rate, thanks for listening, I'm very much enjoying WSL so far...

@oterhals

This comment has been minimized.

Copy link

oterhals commented Oct 8, 2017

Here's another workaround, although not the most elegant one.

If you add this to the end of your .bashrc file, all references to Windows PATHs will be removed. In my case 20 elements are removed and only 8 are left:

PATH=$(/usr/bin/printenv PATH | /usr/bin/perl -ne 'print join(":", grep { !/\/mnt\/[a-z]/ } split(/:/));')

Not sure if this will catch everything, but it does the trick for me.

@markgross

This comment has been minimized.

Copy link
Author

markgross commented Oct 9, 2017

@zbutfly

This comment has been minimized.

Copy link

zbutfly commented Mar 15, 2018

I write a script to resolve it, append . scriptname.sh at your ~/.profile or any other init script else:

#!/bin/bash

IFS=':'
NEWPATH=''

for p in ${PATH[@]}
do
	if [ "${p:0:5}" != "/mnt/" ]; then
		NEWPATH+=":$p"
	fi
done
IFS=' '

export PATH=${NEWPATH:1}
@mpiroc

This comment has been minimized.

Copy link

mpiroc commented Jun 7, 2018

The rationale for closing this bug is that "you need to include the file extension in order to invoke windows executables". But as @irontoby demonstrated (I see the same behavior on my system), this just isn't true. If you invoke foo, Windows considers foo.exe to be a match.

Even with nodejs installed through apt-get, running node still picks up the Windows version, not the Linux version.

I don't believe that this bug should be closed.

@benhillis

This comment has been minimized.

Copy link
Member

benhillis commented Jun 8, 2018

@mpiroc - That's because the node guys removed the .exe extension from their binary.

@mpiroc

This comment has been minimized.

Copy link

mpiroc commented Jun 8, 2018

@benhillis On my machine, it's still present:

pirocchi@LAPTOP:/mnt/c/repos/foo$ whereis node
node: /mnt/c/Program Files/nodejs/node.exe
@benhillis

This comment has been minimized.

Copy link
Member

benhillis commented Jun 8, 2018

@mpiroc - Look in that directory, you'll also find a "node" file with no extension.

@mpiroc

This comment has been minimized.

Copy link

mpiroc commented Jun 8, 2018

pirocchi@LAPTOP:/mnt/c/repos$ ls "/mnt/c/Program Files/nodejs/"
node_etw_provider.man  node.exe  node_modules  node_perfctr_provider.man  nodevars.bat  npm  npm.cmd  npx  npx.cmd
@mpiroc

This comment has been minimized.

Copy link

mpiroc commented Jun 8, 2018

I verified by downloading from https://nodejs.org/en/download/. As of the current LTS release (8.11.2), the .exe extension is still present on Windows, and no additional node file without the extension is present.

@mpiroc

This comment has been minimized.

Copy link

mpiroc commented Jun 8, 2018

@benhillis

This comment has been minimized.

Copy link
Member

benhillis commented Jun 8, 2018

@mpiroc - That is not the behavior I am seeing:

image

@wlerin

This comment has been minimized.

Copy link

wlerin commented Jul 6, 2018

@mpiroc The example earlier calls npm, not node. npm without an .exe is present in your screenshot.

That said, this "feature" mostly just adds meaningless noise, especially to path completions since most files on NT filesystems have their executable bits "set" (or at least bash thinks they do).

@rainabba

This comment has been minimized.

Copy link

rainabba commented Jul 18, 2018

Going to pipe in here also. The ONLY reason I care about WSL was so I could do node.js and Docker development on my Windows workstation. I realize this was an "intentional feature" to cater to people with undisciplined environments where they can chance such things, but are those the people you want to be selecting feature for given the reason (and the only way) that WSL is so demanded (Windows developers wanting full posix environments). WE are impacted negatively by this behavior and the defense is just plain silly, especially in light of this.

When I have to waste time, un-breaking a default setup, something is wrong. NPM is a worse-case offender too because they did as they should have, and stuck with extensionless executables (as it wasn't needed), but NPM is core to why I even want WSL.

@rainabba

This comment has been minimized.

Copy link

rainabba commented Jul 18, 2018

Thanks to Rich Turner on Twitter: https://twitter.com/richturn_ms/status/1019452175523577856?s=19

This should address the issue nicely though I haven't confirmed myself just yet:

https://blogs.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/

@mhamrah

This comment has been minimized.

Copy link

mhamrah commented Jul 19, 2018

I'm curious how people about being able to execute Linux commands via wsl natively from Windows? I'd love for something like VS Code on WIndows to pick up the Linux version of node. I know this was demo'ed as a special case by passing the node command and parameters via the wsl.exe command on the Windows site, but without having Linux PATH support from windows, you have to create a wrapper command for every Linux command you want to expose. Really annoying when it comes to NPM (and Go). Even though these are supported natively on Windows, having the Linux ecosystem and Linux binaries run 'natively' on Windows is a huge benefit for development.

@benhillis

This comment has been minimized.

Copy link
Member

benhillis commented Jul 19, 2018

You can prefix any Linux command you want to run with "wsl" for example:
'wsl ls'

@mhamrah

This comment has been minimized.

Copy link

mhamrah commented Jul 19, 2018

Correct, but I want Windows to automatically prepend 'wsl' based on any commands it finds in my path that are in linux via WSL. This will let things like extensions in vs code call out to 'npm' and have it run the linux version.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

therealkenc commented Jul 19, 2018

prepend 'wsl' based on any commands it finds in my path that are in linux via WSL

That's #1823

@mchiasson

This comment has been minimized.

Copy link

mchiasson commented Aug 27, 2018

I got the same kind of issues than many people here. it picks the wrong ruby, the wrong npm, the wrong perl. etc etc.

To fix it, I just added these two lines in my ~/.profile file:

unset PATH
. /etc/environment

and all of the problems when away:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
@m00head

This comment has been minimized.

Copy link

m00head commented Aug 31, 2018

I have posted the latest workaround for this issue here: #1493 (comment)

@c0ze

This comment has been minimized.

Copy link

c0ze commented Dec 21, 2018

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

this is a horrible call of judgement and I am apalled this has not been fixed yet.

this should not be on by default. It should be other way around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment