Skip to content
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 default umask #1628

Open
KoltesDigital opened this issue Sep 29, 2022 · 1 comment · May be fixed by #2004
Open

DrvFS default umask #1628

KoltesDigital opened this issue Sep 29, 2022 · 1 comment · May be fixed by #2004

Comments

@KoltesDigital
Copy link

Documentation Issue

In the table, default umask is said to be 000. In the text afterwards, it's said to be 022. From my experience, almost all files and directories from DrvFS are 777, so it seems the former is correct.

Besides, it's written that permissions go through an OR, however it's a AND(NOT).

Link to documentation page

https://learn.microsoft.com/en-us/windows/wsl/wsl-config

Suggested Improvements

No response

@jjvliu
Copy link

jjvliu commented Aug 9, 2024

Same issue as #1767 (technically, that one is the duplicate since this came earlier). Should be fixed by #2004.

The core issue is right: the default umask should be documented as 000, based on our testing in WSL. However, regarding the second part of the issue:

it's written that permissions go through an OR, however it's a AND(NOT).

That part of the documentation is correct as written:

The permission masks are put through a logical OR operation before being applied to files or directories.

The masks umask, fmask, and dmask are put through a logical OR. For example, if umask=123,fmask=321,dmask=000, then the final mask actually applied to files is 444 and to directories is 123, so the default permissions for files will be 333 and for directories will be 654.

jjvliu added a commit to jjvliu/WSL that referenced this issue Dec 9, 2024
Resolves MicrosoftDocs#1628 by making docs consistent with real behavior tested in WSL2. (Also resolves MicrosoftDocs#1767 by making the table consistent with the following paragraph, but note from testing, it was the paragraph that didn't match the real behavior, not the table.)
@jjvliu jjvliu linked a pull request Dec 9, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants