Relativity between ACL and WSL permissions

2020 October 7th

Ability for cross integration of Linux and Windows inside WSL is one of the best points of the subsystem but it has its flaws. By default it ships in a way that will sometimes, when editing Windows volume files inside WSL, throw Access denied message. Even though you change the owner permissions and grant full access to everyone on the WSL side, you won't be able to edit the file.

So why does this happen.

With the start of WSL it acted as a separate system running on Windows. Inclusion of mount ability for Windows volumes created a very obvious flaw. Even if the file would be protected by permissions inside the WSL if user would have according permissions in Windows filesystem, he could edit and view the file. In core, the permission bits on each file or folder were derived from Windows no-write bit.

Windows introduced DrvFs as a solution, a filesystem plugin for supporting the inter operations of Windows and WSL. Creation of files is now solved with a metadata attached to file or folder assigned directly from chown/chmod commands. And with it, it introduced the ability to apply umask.

Umask is a command that determines the setting of a mask that controls file permissions. In other words, masks sets the limits of assigning the permissions by the program or any creation entity. Setting umask metadata enables Windows to be able to change metadata for files according to its ACL permissions. Default metadata is possible to be entered in wsl.conf.

Umask excepts the octal argument with 4 digits. If you enter less then 4 digits umask automatically binds 0 to that places.

special permissions (setuid | setgid | sticky)
(u)ser/owner part of the mask
(g)roup part of the mask
(o)thers/not in group part of the mask

Octal codes that are available:

Octal digit inumask command	Permissions the mask willprohibit from being set during file creation
0	any permission may be set (read, write, execute)
1	setting of execute permission is prohibited (read and write)
2	setting of write permission is prohibited (read and execute)
3	setting of write and execute permission is prohibited (read only)
4	setting of read permission is prohibited (write and execute)
5	setting of read and execute permission is prohibited (write only)
6	setting of read and write permission is prohibited (execute only)
7	all permissions are prohibited from being set (no permissions)

Setting the umask argument to 0022 in that case gives us a read/write access to groups and other which makes a workaround with permission problems. It also gives denied execution permission by default.

Besides umask we also have fmask and dmask. Fmask has the same functionality as umask, but it works and is created specifically for FAT filesystems. Masking for FATs is working separately for files and directories and hence we have fmask (file mask) and dmask (directory mask). Dmask in this context is not used. Fmask can be ommited but it is seen on forums and posts, mainly because FAT is still powering USB sticks and SD cards. It has a bit different numeration and in order to set write permission we would use mask 0011.

Putting that in wsl.conf in the end would look like this:

options = "metadata,umask=22,fmask=11