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

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

Closed
laktak opened this Issue Nov 28, 2016 · 14 comments

Comments

Projects
None yet
@laktak

laktak commented Nov 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fpqc

fpqc Nov 28, 2016

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

fpqc commented Nov 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@rodrymbo

rodrymbo Nov 29, 2016

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?

rodrymbo commented Nov 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fpqc

fpqc Nov 29, 2016

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

fpqc commented Nov 29, 2016

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

@laktak

This comment has been minimized.

Show comment
Hide comment
@laktak

laktak Nov 29, 2016

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.

laktak commented Nov 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Jonjoe

Jonjoe May 24, 2017

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

Jonjoe commented May 24, 2017

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

@GoGaetan

This comment has been minimized.

Show comment
Hide comment

GoGaetan commented Nov 7, 2017

@davidalejandroaguilar

This comment has been minimized.

Show comment
Hide comment
@davidalejandroaguilar

davidalejandroaguilar Dec 4, 2017

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.

davidalejandroaguilar commented Dec 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gaurav-nelson

gaurav-nelson Dec 21, 2017

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

gaurav-nelson commented Dec 21, 2017

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

@DarthSpock

This comment has been minimized.

Show comment
Hide comment
@DarthSpock

DarthSpock Dec 21, 2017

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

DarthSpock commented Dec 21, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@therealkenc

therealkenc Dec 21, 2017

Collaborator

Ref #2476

Collaborator

therealkenc commented Dec 21, 2017

Ref #2476

@gaurav-nelson

This comment has been minimized.

Show comment
Hide comment
@gaurav-nelson

gaurav-nelson Dec 21, 2017

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

gaurav-nelson commented Dec 21, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@lucascaton

lucascaton Feb 19, 2018

Any news on this?

lucascaton commented Feb 19, 2018

Any news on this?

@rodrymbo

This comment has been minimized.

Show comment
Hide comment
@rodrymbo

rodrymbo Feb 19, 2018

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

rodrymbo commented Feb 19, 2018

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

@DarthSpock

This comment has been minimized.

Show comment
Hide comment
@DarthSpock

DarthSpock Feb 20, 2018

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

DarthSpock commented Feb 20, 2018

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

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