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

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

Closed
simonbuchan opened this Issue Jun 1, 2018 · 12 comments

Comments

Projects
None yet
2 participants
@simonbuchan

simonbuchan commented Jun 1, 2018

  • 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

This comment has been minimized.

Collaborator

therealkenc commented Jun 1, 2018

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

This comment has been minimized.

simonbuchan commented Jun 1, 2018

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

This comment has been minimized.

Collaborator

therealkenc commented Jun 1, 2018

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

This comment has been minimized.

simonbuchan commented Jun 1, 2018

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

This comment has been minimized.

Collaborator

therealkenc commented Jun 1, 2018

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

This comment has been minimized.

simonbuchan commented Jun 1, 2018

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

This comment has been minimized.

simonbuchan commented Jun 1, 2018

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

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Jun 1, 2018

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

This comment has been minimized.

simonbuchan commented Jun 1, 2018

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

This comment has been minimized.

Collaborator

therealkenc commented Jun 1, 2018

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 therealkenc reopened this Jun 1, 2018

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Jun 19, 2018

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

This comment has been minimized.

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