File permissions check on Windows 10 platform fails about envy HOT 10 OPEN

I just wrapped up a short contracting job where I found out - after starting work - that the client's C# code only worked on Windows. I've been coding on Windows almost every day for the last couple of weeks. The Windows developer experience has come a long way actually but it's still such a pain by comparison.

I haven't had time to look into this issue further just yet, but now that I have a proper development environment set up on Windows, I'll work on it later this week. Your insight is very helpful, @devinivy!

from envy.

@Nargonath worked on Windows support in #2. Maybe they can provide some insight. Supposedly there is some way to set the permissions in such a way that Node.js will read it as 555. It seems we never wrote down how to do it, though. Would be good to document it and link to that documentation from the error message.

Caveats: on Windows only the write permission can be changed

I believe that excerpt from the Node.js documentation is referring to limitations of what fs.chmod() can do, which envy does not use, so this does not apply to us. You are responsible for changing file permissions yourself in userland, either programmatically or from the command line, etc. envy just wants the permissions to be in a certain state before reading any files.

from envy.

I haven't worked on Windows 10 for a long time now. I'm mostly on OSX and Linux these days. Not sure I can provide much, sorry.

from envy.

from envy.

Thanks, I'll leave this open until I have some time to play around with Windows file permissions and see if I can figure out what's necessary to get the 555 that was mentioned in #2. It will probably take a long time for me to get around to it, though. I only use Windows for gaming.

from envy.

I am not a Windows user, but I have done some research into this since I am interested in Windows support.

• Under WSL users can achieve any file permissions if they enable metadata on their mount. It is worth noting that Linux permissions that are placed in metadata can only further limit access to a Windows file, and never expand access.
  • For more info see https://docs.microsoft.com/en-us/windows/wsl/file-permissions. I know that ssh checks file permissions similarly to envy, so I searched for questions about how to fix ssh permissions in WSL, and the accepted answer is generally to enable metadata then set the file mode with chmod. So it's nice to know this works and seems to be pretty common.
• Under non-WSL, Windows has an ACL system that does not map down nicely to Unix file modes, so you get an approximation of the user's Windows permission duplicated for user, group, and world. In this scenario there is no way to infer whether the permissions are appropriate since we only care about group and world permissions, which we have no information about. I don't think there's a ton of value in ensuring that the file is marked as Read-Only (a Windows permissioning concept) since it still might be readable or writable by other users— plus it's perfectly valid for the user to have access to write this file.

My recommendation would be to treat WSL identically to Linux (perhaps with a note in the readme/error message about the metadata caveat) and to disable the check by default for non-WSL Windows. Worth noting that right now envy treats WSL and non-WSL Windows identically, which means that WSL is catering to Windows as the lowest common denominator.

I think reading this comment in libuv was what made me realize that non-WSL Windows just wasn't going to allows us to check permissions in the way we'd like to do, and may even cause further confusion for users: https://github.com/libuv/libuv/blob/9c3d692b3941a2a4171629fb52af2e1029c415e8/src/win/fs.c#L1731-L1749

from envy.

Under WSL users can achieve any file permissions if they enable metadata on their mount.

Is there a way to enable metadata from the command line? I'd prefer to only enforce permissions where the error message can provide a simple fix.

I know that ssh checks file permissions similarly to envy

Indeed! Envy is partly inspired by and modeled after SSH. It would probably be a good idea to add that to the documentation.

My recommendation would be to treat WSL identically to Linux

Makes sense to me as long as metadata can be enabled easily.

One thing I'm wondering about now is why Windows users seem to only have trouble with the .env file permission check and not the one for .env.example.

from envy.

Is there a way to enable metadata from the command line? I'd prefer to only enforce permissions where the error message can provide a simple fix.

My understanding is that it's a mount option. So I believe it can be done by CLI or a config file but you would have to restart WSL to re-mount the drive.

One thing I'm wondering about now is why Windows users seem to only have trouble with the .env file permission check and not the one for .env.example.

That's a good point and question. I don't really know the answer to that, but of course the check is much more strict. Actually this issue just occurred to me: non-WSL Windows users have their Windows file perms interpreted by node (I believe 444 read-only or 666 read/write), but WSL Windows users without metadata have their Windows file perms interpreted by WSL (I believe 000 no perms, 555 read-only, or 777 read/write, possibly slightly more expressive but always xxx). So non-WSL Windows users might be out of luck: their .env.example would pass if it's 444, but the .env would not pass if it's 444 and there's no way to make it 555.

And we could possibly fix that, but the core question for me is: are these cases helpful to envy's intention? If we only know the permission for the file owner then we can't say much about how secure the file is. Giving instructions for the user to mark their file as read-only (I believe the only recourse) could vary depending on whether the user is using command prompt, powershell, git bash, cygwin, or wsl, and in my opinion is an awkward request. The one Windows case where we have more information is WSL with metadata enabled, and enabling metadata means a re-mount.

Sorry for the wall of thoughts and information, and maybe some disappointing results! It has been interesting to dig into, and I think we're nearing a solution (of sorts 🤣). Sort of too bad we don't have a daily Windows user here to chime in.

from envy.

Actually my last comment of 2019 is not accurate anymore. I now work purely on WSL2 for almost a year. I haven't enabled the metadata yet. If you need me to run some tests feel free to ask. 👍

from envy.

@Nargonath the most helpful thing at this point would be to let me know if there's some way to enable metadata from the command line; any command line, PowerShell, bash, etc. Because if there isn't, I'll need to think a little bit more about whether I want to make people jump through those extra hoops.

from envy.