warning: Insecure world writable dir /mnt/c in PATH, mode 040777

[laktak]

When I run Ruby gems I often see the warning

warning: Insecure world writable dir /mnt/c in PATH, mode 040777

This is coming from Ruby, the shortest way to reproduce that I could find (though I'm no Ruby dev) is this:

$ ruby -e '`true`'
-e:1: warning: Insecure world writable dir /mnt/c in PATH, mode 040777

$ ls -la /mnt
[..]
drwxrwxrwx 0 root root 0 Nov 21 21:18 c
[..]
$ echo x > /mnt/c/ok
-bash: /mnt/c/ok: Permission denied

Not sure how this should be handled - maybe Windows file permissions could be better mapped on the mounts.

OS Name: Microsoft Windows 10 Enterprise Insider Preview
OS Version: 10.0.14971 N/A Build 14971

[fpqc]

@laktak Yeah, that's because /mnt/c is mounted with the umask=000. The actual Windows permissions there are not visible to the Linux-side, though they are enforced. Anyway, yes, it is a known issue that /mnt/c being mounted the way it is (and also other permissions on interop) do not make WSL secure as an actual server platform.

For example, there is nothing stopping you, if you control a simple Linux user in a WSL instance, from dropping an executable in the startup folder that will then replace /etc/shadow the next time the Windows user logs in and out to give you root access.

Even worse, you could actually overwrite /etc/shadow by dropping into cmd.exe and overwriting /etc/shadow from there. I'm sure the devs are aware of this, and that's why they definitely do not recommend running WSL as a server platform (also the disk i/o performance would be pretty atrocious for such a purpose). This will likely change in the future.

[rodrymbo]

Another way to put it is "why did you add an insecure path like /mnt/c to your PATH environment variable?" On a regular linux box, if it is used by multiple persons, one might have a shared directory where people might be able to drop files for other people to access, but one certainly wouldn't add it to one's PATH or casually execute a random file one found there.

The issues @fpqc mentions are not trivial, but they are mitigated by the ability to keep other people off one's machine or at least keep them from logging in to your own WSL subsystem. If you want to install executable files onto /mnt/c and use them, and you are reasonably sure no one else is likely to mess with files there, there's nothing to stop you. And of course, executables you install (with sudo) into /usr/local/bin are not flagged as insecure.

We've already asked for the ability to install the WSL subsystem to a location other than our smallish ssd c: drives. I'm thinking that's what the issue is? Otherwise, why install things onto the mounted NTFS filesystem instead of putting them in /home or /usr/local/bin or /opt?

[fpqc]

@rodrymbo Because this is probably ruby executing scripts residing in a directory where he's doing interop between Windows and Linux tools.

[laktak]

Another way to put it is "why did you add an insecure path like /mnt/c to your PATH environment variable?"

AFAIK this is the default - the Windows path is added by the system so you can launch Windows executables.

[Jonjoe]

Hey! Is there anyway to silence this error? Its messing up my pretty terminal :( </3.

[GoGaetan]

sudo chmod 755 /usr.

You can read more in this post.
https://stackoverflow.com/questions/32325413/warning-insecure-world-writable-dir-usr-in-path-mode-040777

[davidalejandroaguilar]

This is happening to me too on Ubuntu 16.04.3 LST Xenial, didn't happen on previous (I think it was Trusty). Any ideas of how to silence this? #81 chmod doesn't seem to be working.

[gaurav-nelson]

I removed all windows path mentions from PATH to resolve this error by running:
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

[WSLUser]

@gaurav-nelson and you just effectively killed your interop with Windows. Hope you don't use anything from there. If you do, might as well reinstall WSL now because it's alot less painful than trying to remap your paths from Windows. That being said, it may be easier to fix those particular issues thanks to 17063 and the introduction of WSLENV.

[therealkenc]

Ref #2476

[gaurav-nelson]

@DarthSpock yes I am not using it for any interop things. I always keep backup, So I do have a backup for PATH before I changed it. And I did this into another WSL instance (not my main one)

[lucascaton]

Any news on this?

[rodrymbo]

@lucascaton: News on the way all the files in /mnt/ have the same owner and group (on the emulated/apparent Linux filesystem)? Or on the error message you get when you run a program that checks the PATH for world writable files?

For the error message, standard Linux best practice is to set up your PATH for each script or environment. So if you are running a script that only needs access to /usr/local/bin, make sure that is the only thing in the PATH. On a regular Linux machine there are frequently paths in the normal user login PATH that are there for convenience, and should not be included when running, say, a service or cron job in production. It's also best to include a full path to each executable in production scripts, rather than relying on PATH. From that perspective, the solution is to take /mnt/c (if that is what is causing the message) out of the PATH when using that script or environment. It's also possible the Windows Path (from which the default Linux PATH is being derived) has unneeded paths in it, and one could remove them.

As for whether /mnt/c is world writable: on my Build 17101, permissions seem to vary from 111 to 777 on my machine, apparently depending on the permissions on the underlying NTFS filesystem, with swapfile and pagefile undefined. The chmod command doesn't appear to work as expected under /mnt (DrvFS), but I haven't changed the mount options that appear to be available since Build 17063.

There's also the recent workaround of setting up and mounting another, isolated WSL linux filesystem on which the emulation works pretty much as expected. The task there would be to unmount all the /mnt (DrvFs) volumes and only include the emulated WSL filesystems (LxFs) in the PATH. That would eliminate the error message and make the actual functionality much more comparable to a regular Linux environment. (The main reason for doing this would be if the root filesystem is on a smallish SSD and one needs more space for development or whatever you are doing there.) There would still be oddities and insecurities, but they'd (mostly) only be significant if you tried to use WSL for production.

[WSLUser]

@rodrymbo WSL - Windows permission interop is in place, did you enable the metadata? Also recommend instead of mounting via DrvFS, using fstab instead. wsl.conf could greatly assist you with this as a time-saver. chmod/chown could change those permissions at that point though of course at the risk of breaking something.

[dayne]

Just an FYI for others running into this problem and finding this closed issue...

You can remove all those /mnt/c paths from your $PATH with the following line:

export PATH=`echo $PATH | tr ':' '\n' | awk '($0!~/mnt\/c/) {print} ' | tr '\n' ':'`

If you add that line to your .bashrc file it will automatically be run ... do that only if you are sure you don't want those windows bin dirs in your path. You can always remove the line from .bashrc to bring them back.

[dsloyer]

I was able to permanently squelch the pesky "insecure world writable dir /mnt/c" by adding the following text to /etc/wsl.conf:
[automount]
options="metadata,umask=0033"

[malongshuai]

I had the same problem.
I supressed this noise by redirecting pry's stderr to null device:

$ pry --simple-prompt 2>/dev/null

Alias this command line in bash profile for future：

echo "alias pry='pry --simple-prompt 2>/dev/null'" >>~/.bashrc
exec $SHELL

so, everything is fine:

$ pry
>> 1.class
=> Integer

[therealkenc]

This one is in the squarely buried pile. It would be better if WSL behaved more like common Linux distros by default with respect to mounting external volumes. Something like /media/<username>/<volume-guid>/ with the mountpoint permissions 755, and the uid:gid for each WSL <username> with an active WSL session. Then, as WSL-specific behavior, bind mount /mnt/<driveletter> to /media/<username>/<guid>, with each user session "seeing" a different bind mount.

[While there, a wsl.conf option "automount_prefix" (or somesuch) would help those who have all their docker scripts assuming the mountpoint is /c not /mnt/c. For better or worse this is a massively common use case.]

@dskoyer's post from February is a good work-around / interim-solution.

[Kenan7]

export PATH=echo $PATH | tr ':' '\n' | awk '($0!~/mnt\/c/) {print} ' | tr '\n' ':'

there isn't way to undo this operations, is there? 🤦‍♂️ It messed up my paths. I can't open vscode in ubuntu terminal

[Kenan7]

export PATH=echo $PATH | tr ':' '\n' | awk '($0!~/mnt\/c/) {print} ' | tr '\n' ':'

there isn't way to undo this operations, is there? 🤦‍♂️ It messed up my paths. I can't open vscode in ubuntu terminal

restarting solved it

[dayne]

I ran into this issue to and solved it by writing up a vscode-server detector and path adder to my .bash.d loaders:

if [ -d $HOME/.vscode-server ]; then
  # ensure there is only one thing to add to path
  if [ `ls $HOME/.vscode-server/bin/*/bin | wc | awk '{print $1}'` == 1 ]; then
    vscode_bin=`ls -d $HOME/.vscode-server/bin/*/bin`
    #echo "detected vscode-server - adding to path: $vscode_bin"
    PATH=$PATH:$vscode_bin
    export PATH
  fi
fi

[nrohankar29]

I was able to permanently squelch the pesky "insecure world writable dir /mnt/c" by adding the following text to /etc/wsl.conf:
[automount]
options="metadata,umask=0033"

@dsloyer where is the /etc/wsl.conf file located?

[thiagopecanha]

I was able to permanently squelch the pesky "insecure world writable dir /mnt/c" by adding the following text to /etc/wsl.conf:
[automount]
options="metadata,umask=0033"

@dsloyer where is the /etc/wsl.conf file located?

"wsl.conf is located in each Linux distribution in /etc/wsl.conf. If the file is not there, you can create it yourself. "

@nrohankar29 https://docs.microsoft.com/en-us/windows/wsl/wsl-config#configure-per-distro-launch-settings-with-wslconf

[smoore4moma]

I was able to permanently squelch the pesky "insecure world writable dir /mnt/c" by adding the following text to /etc/wsl.conf:
[automount]
options="metadata,umask=0033"

THEN REBOOT WINDOWS.....otherwise it does not work rightaway.

[xpuu]

THEN REBOOT WINDOWS.....otherwise it does not work rightaway.

or run wsl.exe --shutdown from your cmd/powershell prompt

[Raghav-Bell]

I am unable to install jekyll due to this error while running :
gem update
and also I am unable to find wsl config file in /etc .
for complete problem please see :stackoverflow

[iuriguilherme]

TL;DR: Inside the WSL terminal, use notepad.exe /etc/wsl.conf, paste this, save the file and reboot:

[interops]
appendWindowsPath = false

---

If you rely on things installed from the Windows side or you use the windows filesystem to install things, this will break everything for you. This would be a good time to ask yourself why are you doing this. The WSL distros have a ext3 virtual disk which you can only manipulate properly if you have Hyper-V in the windows pro version, but it does the job.

The contents of the file /etc/wsl.conf inside the filesystem of each one of your WSL Linux distro you don't want the windows environment's PATH appended to Linux PATH:

[interops]
appendWindowsPath = false

If you want to go further and mount the (probably NTFS) underlying windows filesystems with the posix default umask - if you don't know what that is, you shouldn't do it:

[interops]
appendWindowsPath = false
[automount]
options = "metadata,uid=1000,gid=1000,umask=022"

---

To edit that file you must do it from inside the distro, for example with sudo nano /etc/wsl.conf or sudo vim /etc/wsl.conf. You can also edit is from windows with a command like notepad.exe /etc/wsl.conf. This is a per distro configuration, and only applies at their boot time.

Reference: https://docs.microsoft.com/en-us/windows/wsl/wsl-config#configuration-settings-for-wslconf

[Raghav-Bell]

Thanks @iuriguilherme for your answer . It seems it is lot eaier to run jekyll on Linux (VM) then on WSL2.