DrvFs mount is unable to use a subdirectory as source

[heldchen]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  17063

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

root@devbox:~# mount -t drvfs "D:\\projects\\someuserproject" /mnt/test -o metadata,uid=someuser,gid=someuser
mount: /mnt/test: wrong fs type, bad option, bad superblock on D:\projects\someuserproject, missing codepage or helper program, or other error.
root@devbox:~# mount -t drvfs D:/projects/someuserproject /mnt/test -o metadata,uid=someuser,gid=someuser
mount: /mnt/test: special device D:/projects/someuserproject does not exist.
root@devbox:~# mount -t drvfs D: /mnt/test -o metadata,uid=someuser,gid=someuser
root@devbox:~#

• What's wrong / what should be happening instead:

with the new -o options to set uid & gid it would make very much sense to be able to specify a path as source for mount instead of the entire drive. giving a local wsl user full right on the entire drive could be quite dangerous.

[therealkenc]

giving a local wsl user full right on the entire drive could be quite dangerous.

The ask is reasonable enough, but the assertion is incorrect. WSL doesn't have any rights to /mnt/c that the cmd.exe it came from doesn't have. If you gave your Windows user Administrator rights and feel that's unsafe, well, "don't do that".

[heldchen]

with "full right" I mean the same rights as the wsl distro owner... usually my user account which has enough rights on the drive D to f.e. remove most folders.

a wsl user that is not the main user or root should not be able to do that, but seems to be able with the new uid/gid mount options.

allowing subdir mounts would keep the user's rights confined within the mounted dir...

[therealkenc]

allowing subdir mounts would keep the user's rights confined within the mounted dir...

No because any user can do wslprompt$ cmd.exe /c rd /q /s D:\\path\\to\\anywhere. You could, I suppose, echo 0 > /proc/sys/fs/binfmt_misc/WSLInterop. But if you did that, there wouldn't be much point in your 'not-you' user storing anything in /mnt/sandbox/notyou, as opposed to their /home, would there.

None of which is to imply this isn't a sensible ask. Hope it gets considered. See also bindfs.

[heldchen]

hmm right. I was more in the line of thinking that one of my bash scripts having a bug and wrecking havoc than a targeted wsl attack. the first is much more likely tbh :-)

/proc/sys/fs/binfmt_misc/WSLInterop could be a way to prevent your attack in my case tho: I'm using WSL as an replacement for "real" vms to run & test stuff in a similar debianish environment as on our production servers and do not need to call windows binaries from the wsl instance.

[diablodale]

I have a workaround you can try with build 17074.
Use drvfs with the UNC path to the source subdirectory.

If your goal is to map
source: C:\Users\Bob\Documents
dest: /home/robert/docs

Then
mount -t drvfs '\\localhost\c$\Users\Bob\Documents' /home/robert/docs

This worked for me and I can additionally use the -o options to change uid, gid, umask, etc.

[heldchen]

unfortunately this makes it even slower by going through SMB. too bad mount -t drvfs '\\?\C:\Windows' /mnt/test fails with Host is down.

[diablodale]

Naturally, this workaround will cost you some number of nano or milliseconds more than the local filesystem codepath. However, keep in mind that your local drive (spinning or SSD) is still the larger delay and time cost; still magnitudes slower than either codepath.

This UNC workaround, which uses the local loopback shortcut, works now until some maybe future when WSL supports native subdir mounts.

You can't use \\?\ as that format only denotes long path names and not to create a UNC. Nice try though. ;-)

[heldchen]

unfortunately that's only meaningful if the files are large enough. I'm working on a project with ~80k rather small files, of which around 44k are regularly regenerated/compiled. going through the network stack adds significant overhead - been there with vmware workstation on local machine.

[therealkenc]

In some unrelated issue (too much effort to search) Sven pointed out very helpfully that you can use a bind mount to achieve this. That's probably a better way to roll than exporting a CIFS share and then mounting the share.

[cdenneen]

The bind worked. Issue I’ve run into is the git checkout with symlink enabled in git config. Gives permission denied when run from windows git bash but seems to work from WSL. Haven’t had time to fully document the issues but definitely had issues when running VSCode and WSL controlling same repo that happens to have symlinks.

…

On Tue, May 29, 2018 at 9:06 PM therealkenc ***@***.***> wrote: In some unrelated issue (too much effort to search) Sven pointed out very helpfully that you can use a bind mount <https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount> to achieve this. That's probably a better way to roll than exporting a CIFS share and then mounting the share. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2778 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAr84RWHqkPzCTQ_xKv8CwcGHzixnSTQks5t3fCTgaJpZM4RKhaQ> .

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!