drvfs fmask=111 breaks (e.g.) cmd.exe without workarounds?

[simonbuchan]

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

Microsoft Windows [Version 10.0.17134.81]

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

Not sure if I'm just missing something here? When using fmask=111 as used as an example in the post introducing the feature using windows .exes doesn't work - OK, that's as expected. The problem is that there doesn't seem to be a way to chmod +x things in /mnt/c/Windows - even UAC elevated + sudo doesn't help:

% sudo chmod +x /mnt/c/Windows/System32/cmd.exe
[sudo] password for simon:
chmod: changing permissions of '/mnt/c/Windows/System32/cmd.exe': Permission denied

Removing +x permission from drvfs files by default is a really big win, because git preserves the +x permission on filemode-supporting filesystems, and otherwise can only be set via git add --chmod=+x or git update-index --chmod=+x (from memory).

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

Not really sure what the right answer here would be: pre-chmod'ing windows executables? Path/glob-based *mask configuration? Permitting chmod of system files somehow?

[therealkenc]

The problem is that there doesn't seem to be a way to chmod +x things in /mnt/c/Windows - even UAC elevated

"Surprised" it doesn't work UAC elevated, even though changing the Unix mode of stuff in .../System32 is Just Wrong™ (scary quotes because I'm not really all that surprised that is verboten).

Work around if you are hellbent on a fmask=111 on some directories but really want (say) mode=755 on System32 is to mount -t drvfs C: more than once on different points with different fmask. I recommend against any of this mind you. There is no "win" down this river.

Someone from the team will have to weigh in on why you can't chmod say NOTEPAD.EXE (by-design or otherwise). I haven't tried am not about to. Bonne chance.

[simonbuchan]

There's lots of weird ACL rules on C:\Windows stuff, e.g.:

C:\Users\simon>icacls C:\windows\system32\cmd.exe
C:\windows\system32\cmd.exe NT SERVICE\TrustedInstaller:(F)
                            BUILTIN\Administrators:(RX)
                            NT AUTHORITY\SYSTEM:(RX)
                            BUILTIN\Users:(RX)
                            APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)
                            APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APP PACKAGES:(RX)

I'm sure I could stomp permissions on these to get the chmod applied (somehow - icacls /? is a dark and mysterious forest), but I suspect windows' system file protection would kick in at some point.

[therealkenc]

Yep. I deleted a bit of my last post before submission because I didn't want to get lost in the DACL weeds. These days you can't even rename/replace (say) notepad.exe without jumping through hoops. It can be done. On reflection there is not much to "weigh in" on per the last paragraph in my previous post. This is pretty squarely by-design behaviour. Mounting C: on multiple points isn't really a "work-around" either, because nothing is "broken". It is how you'd get the intended semantics, again by-design.

I'll hold this open for a bit on the chance someone else jumps in with something more to add. But this feels like a wrap.

[simonbuchan]

Not sure what you mean - yes, each part is behaving as designed, which when combined makes them not work in a useful way - this is what an issue is 😉.

Clearly there are plenty of options that don't involve users modifying system files, my original post suggests two others, and here's another two:

• store chmod info in a separate per-user lookup
• as with case=dir, enable masking on a per-directory basis.

I opened this issue so WSL could try to have a solution that actually does the right thing by default here, which it's gotten a lot better at over time.

Custom mounts are a pretty bad solution, but at least they are one. The problem is that you have to mount "stuff I might want to actually edit with WSL" in the custom fstab entry, because the other way around makes the 16 entries (or whatever) you have in %PATH% all broken. But you still have the automount that if you accidentally use, will display every non-chmodded file as 777, meaning it's all to easy to git commit every file as changed to +x. And it's way to easy to do that, as using bash or wsl from windows will automap paths to that.

[therealkenc]

Not sure what you mean

I mean this issue# is a hair from closed-bydesign. None of your proposals (along with the per-directory case sensitivity, but I digress) have a POSIX/Linux syscall API nor companion tooling. At base, multiple mounts is a "bad solution" (for the sake of argument only) because there is no "win" down this path in the first instance.

The right place to submit a new WSL syscall API for any one of your proposals would be in UserVoice. To be clear: I am not even discouraging you from doing that. Stranger things (again, per-directory case sensitivity) have happened. Who knows.

[simonbuchan]

Huh? Again, this is a very confusing response.

This change would presumably be under either DrvFS or WSL -> win32 interop, both of which are pretty clearly in scope and have had multiple non-syscall related changes over the last year? And I have no idea where the line on "companion tooling" is. Does wsl.conf count? Presumably fsutil.exe does, what if this is an option to that?

I am incredibly confused by the claim that "there is no win down this path" especially - what does that even mean? The request is roughly "please make it so things can work how they obviously (for a user) should be working" (i.e. posix in general expects no +x by default, wsl should be able to run exe's) - that's a "win", but it doesn't seem like what you meant by that sentence?

I get the feeling these replies are coming from through Raymond Chen's infamous kernel-colored glasses, because right now, from a users point of view they're simply bizarre.

To be clear, I explicitly didn't say what solution I want because I have no idea what he right fix here would be, or if anything I suggested would work.

If instead of a WSL change the answer is "this sucks, but it can't be changed without making things worse", ok, I have to believe the people that work on this. If it's "you don't want to do X, you want to do Y", then I'll see if that works, and if so great, if not then we can go from there. But right now you've suggested Y, and I've said why that is much worse than WSL making some change to fix this, and you've replied with "then that's a feature request". This is a strange reply to me, because fmask=111 seems like it's the 90% case for using the DrvFS options at all, (hence it being the first example in the blog!), so it breaking the 90% case for WSL at all definitely feels like it falls on the bug side.

I'm sorry for so much text.

[simonbuchan]

... no actual reply to any of my points or questions? Are you being deliberately passive aggressive?

[therealkenc]

And I have no idea where the line on "companion tooling" is

Companion tooling are applications like ls, stat, chown, chmod, mount, and other *nix tools.

Presumably fsutil.exe does, what if this is an option to that?

If you are proposing a win32 side solution to your ask, sure. Sounds good to me.

that's a "win"

If you believe it is a win, great.

It was not my intent to come across as passive aggressive; apologies if it did. Once you have a concrete proposal to improve WSL it is very welcome in UserVoice.

[simonbuchan]

Closing without a comment as a reply is generally pretty hard to take otherwise.

Companion tooling are applications like ls, stat, chown, chmod, mount, and other *nix tools.

Ah, this is normally called "user space" (as opposed to kernel), or in the case of WSL, effectively just the distro.

If you believe it is a win, great.

This doesn't seem to follow the conversation at all? It's a reply to a reply to:

because there is no "win" down this path in the first instance.

So the point isn't what I believe, so again, if intended this just reads as very passive aggressive!?

The problem with a uservoice proposal is that I don't know what the right answer here is. The reason I mentioned several options was to point out I don't much care what the feature / change actually is, so long as windows editors, chmod and git work together "properly". When I'm on a keyboard again I'll see if I can figure out something appropriate though.

[therealkenc]

Tell you what; I will mark this as discussion for the time being and let it play out. I will not be participating further. Having rejected (or misunderstood) my intent, I have nothing further to offer you on this topic. Bonne chance.

[therealkenc]

Ran course. The right place to submit a new WSL API or a new win32 API for any one of your proposals would be in UserVoice.

[simonbuchan]

Fair enough: I forgot to get back around to posting this, there.

https://wpdev.uservoice.com/forums/266908-command-prompt-console-windows-subsystem-for-l/suggestions/34597972-making-drvfs-fmask-111-usable

[Volune]

Sorry replying to an old issue, but maybe this workaround can help someone else (at least works for me):

/etc/wsl.conf

[automount]
enabled = false
mountFsTab = true

/etc/fstab

LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
C: /mnt/c drvfs defaults,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off 0 0
//localhost/C$/Windows/System32 /mnt/c/Windows/System32 drvfs defaults,ro,noatime,uid=1000,gid=1000,fmask=222,umask=222,case=off 0 0

[simonbuchan]

Neat trick! I wonder if there's a possible problem with the exe's running with NFS semantics, but it's probably not a problem with the system .exe's you would be using, and of course you could flip to ro,mask=222 for C: and fmask=111 for whatever working dir(s) you want write access in case of trouble.
If drvfs could support this, e.g. mounting C:\Windows\System32 /mnt/c/Windows/System32 drvfs ..., that would work fine for me (if not ideal).

[simonbuchan]

You probably also want these entries for other common $PATH locations, the \040 for space in fstab tripped me up (obviously, change simon in the last line to your user name):

//localhost/C$/Program\040Files /mnt/c/Program\040Files drvfs defaults,ro,noatime,uid=1000,gid=1000,fmask=222,umask=222,case=off 0 0
//localhost/C$/Program\040Files\040(x86) /mnt/c/Program\040Files\040(x86) drvfs defaults,ro,noatime,uid=1000,gid=1000,fmask=222,umask=222,case=off 0 0
//localhost/C$/Users/simon/AppData /mnt/c/Users/simon/AppData drvfs defaults,ro,noatime,uid=1000,gid=1000,fmask=222,umask=222,case=off 0 0

[therealkenc]

//localhost/C$/Program\040Files /mnt/c/Program\040Files drvfs defaults,ro,noatime,uid=1000,gid=1000,fmask=222,umask=222,case=off 0 0

Post from the devs not five days ago:

It is strongly not recommended to mount DrvFs this way for local filesystems.

You can mount bind mount them as mentioned. [Setting aside that the OP was about chmod, not DrvFS mountpoints.]

[Volune]

"bind mount" AFAIK doesn't change fmask, so it's out of topic.
The point is to have a workaround to be able to execute exes while mounting the disk with fmask=111.
Someone who wants a full solution should probably ask on UserVoice.

Also the devs said:

This is both a lot slower and lacks quite a bit of functionality, including metadata, case sensitivity, and indeed symlinks.

In this workaround example, symlinks and case sensitivity are probably irrelevant (I don't know if case=off works), metadata are not used, it's mounted in read-only. And performance is only a concern if exes are called frequently from WSL.
But yes, if someone needs performance or symlinks, the workaround will probably not work.

[simonbuchan]

Someone who wants a full solution should probably ask on UserVoice.

cough

[Setting aside that the OP was about chmod, not DrvFS mountpoints.]

Ehh, not really, I was saying that the natural solution would be to chmod +x the files you want executable, but that it's not possible at all to do that. I would be most happy with a configurable drvfs level solution, since that's where the issue is being caused, but I'll take anything.

[therealkenc]

"bind mount" AFAIK doesn't change fmask, so it's out of topic.

You have to bind a different mount with alternative permissions. Which is what was stated in the first reply to this issue submission in June of 2018.

None of which are work-arounds. [edit[ You would do the same thing on Real Linux with ntfs-3g as standard operating procedure, if for some heretofore undisclosed use case you wanted fmask=111 on some sub-directories of your NFTS drive and not others.

^--- Reflected on that a bit after trying Simon's setup. That probably wouldn't work as described, and thus my saying it would be "standard operating procedure" is incorrect (and deserves correction). You'd need bindfs, I think (and that is a whole other kettle of fish). Bindfs was brought up in passing ref #1240 here.

I was saying that the natural solution would be to chmod +x the files you want executable

That would fail on Real Linux too. Naturally. Because /mnt/c/WINDOWS/system32/notepad.exe is not a filesystem path that has Unix semantics.

In any case, I only dropped by to ensure Sven's post was not lost, and to set up a landing zone for the eventuality that someone puts //localhost/C$ in their fstab anyway.

[simonbuchan]

Am I missing something?

0 ~ 1 % cat /etc/fstab
LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
C: /mnt/c drvfs defaults,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off 0 0
C: /mnt-ro/c drvfs defaults,ro,noatime,uid=1000,gid=1000,fmask=222,umask=222,case=off 0 0

/mnt-ro/c/Windows/System32 /mnt/c/Windows/System32 none bind
/mnt-ro/c/Program\040Files /mnt/c/Program\040Files none bind
/mnt-ro/c/Program\040Files\040(x86) /mnt/c/Program\040Files\040(x86) none bind
/mnt-ro/c/Users/simon/AppData/Local /mnt/c/Users/simon/AppData/Local none bind

0 ~ 0 % mount
rootfs on / type wslfs (rw,noatime)
none on /dev type tmpfs (rw,noatime,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,gid=5,mode=620)
none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)
none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime)
none on /run/shm type tmpfs (rw,nosuid,nodev,noatime)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,noatime,mode=755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
C: on /mnt-ro/c type drvfs (ro,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
C: on /mnt/c/Windows/System32 type drvfs (ro,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
C: on /mnt/c/Program Files type drvfs (ro,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
C: on /mnt/c/Program Files (x86) type drvfs (ro,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
C: on /mnt/c/Users/simon/AppData/Local type drvfs (ro,noatime,uid=1000,gid=1000,fmask=111,metadata,case=off)

This is on build 18356

[simonbuchan]

I'd guess even an immediate fix would have an approximately negative chance to get into 19H1 anyway, so no hurry.

[therealkenc]

I'd guess even an immediate fix would have an approximately negative chance to get into 19H1 anyway

Do-over of my deleted post (I removed it because I figured it was worth pursuing tonight).

Am I missing something?

Tried your setup on a lark. Your fmask=222 on /mnt-ro/c isn't taking, which appears to be incorrect behavior (from here, anyway). This has not been reported before -- probably for lack of a reason to do any of this, and therefore lack of anyone who has tried it and complained.

I've opened #3963. If an alternate fmask takes with DrvFS over SMB but not DrvFS over NTFS, then Sven's "strongly not recommended" advice backs people into a blind alley.

A more straightforward repro looks something like:
$ sudo mkdir -p /tmp/mnt111 && sudo mkdir /tmp/mnt222
$ sudo mount -t drvfs C:\ /tmp/mnt111 -o "metadata,fmask=111"
$ sudo mount -t drvfs C:\ /tmp/mnt222 -o "metadata,fmask=222"
$ mount | grep /tmp/mnt
C:\ on /tmp/mnt111 type drvfs (rw,relatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
C:\ on /tmp/mnt222 type drvfs (rw,relatime,uid=1000,gid=1000,fmask=111,metadata,case=off)

This all said, we are probably going to get an ENOTSUPPORTED response on the new submission and a trip to UserVoice (if there is a response). But at least it is a well formed set of repro steps, and maybe we'll even get lucky. Appreciate the follow up because I wouldn't have looked if you hadn't.