重装系统，又折腾了一遍WSL环境，记录一下:
WSL (Windows Subsystem for Linux) 通过 /mnt 目录下的 c、d、e 等目录可分别访问本地的 C、D、E 等盘，虽然可以直接访问 Windows 下的文件内容，但输入 ls -al 查看文件你会发现文件权限全都是 777。这会导致一些问题出现，比如 Git会保留这些文件的执行权限，如果你之前在 Windows 下使用过 Git Bash ，那么在 WSL 中使用 git status查看本地仓库的文件状态时你会发现它们全部被标记成了 modified。
分析问题
首先要了解 WSL 中的两种文件系统：
VolFs
着力于在 Windows 文件系统上提供完整的 Linux 文件系统特性，通过各种手段实现了对 Inodes、Directory entries、File objects、File descriptors、Special file types 的支持。比如为了支持 Windows 上没有的 Inodes，VolFs 会把文件权限等信息保存在文件的 NTFS Extended Attributes 中。
WSL 中的 / 使用的就是 VolFs 文件系统。
DrvFs
着力于提供与 Windows 文件系统的互操作性。与 VolFs 不同，为了提供最大的互操作性，DrvFs 不会在文件的 NTFS Extended Attributes 中储存附加信息，而是从 Windows 的文件权限（Access Control Lists，就是你右键文件 > 属性 > 安全选项卡中的那些权限配置）推断出该文件对应的的 Linux 文件权限。
所有 Windows 盘符挂载至 WSL 下的 /mnt 时都是使用的 DrvFs 文件系统。
简单来说就是 WSL 对 / 目录下的文件拥有完整的控制权，而 /mnt 目录中的文件无法被 WSL 完全控制（可修改数据，无法真实的修改权限）。WSL 对 /mnt 目录中权限的修改不会直接记录到文件本身，而在 Windows 下对文件权限的修改直接可作用到 WSL 。关于权限在 微软开发者博客中有更详细的说明。
解决方案
这只是让文件在 WSL 中的权限看起来正常（目录 755，文件 644），实际并不会作用到 Windows 文件系统下的文件本身。
在 /etc/wsl.conf 中添加以下配置：
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=22,fmask=111"
mountFsTab = true
上面的方法对所有盘符都有效，如果你想在 WSL 中调用 Windows 下的应用程序（比如 explorer.exe . 调用资源管理器打开当前路径） 就需要对 C 盘进行单独设置，否则会提示没有权限。 首先确认 wsl.conf 中的 mountFsTab 没有被设置为 false，然后编辑 /etc/fstab，添加如下内容：
C:\ /mnt/c drvfs rw,noatime,uid=1000,gid=1000,metadata,umask=22,fmask=11 0 0
此时执行mkdir等命令的时候，会发现新建的目录权限依然是 777。
目前民间解决方案是在.profile、.bashrc、.zshrc 或者其他 shell 配置文件中添加如下命令，重新设置 umask
[filesystem]
umask = 022
全部设置完成之后，重启Windows系统或者重启wsl
net stop LxssManager
net start LxssManager
参考:
https://p3terx.com/archives/problems-and-solutions-encountered-in-wsl-use-2.html