May be somewhat related to #167 , /etc/profile is supposed to be read if bash is a login shell - but even bash.exe --login doesn't seem to use pam_umask

@simonbuchan Thanks for reporting this. I think there are a couple things going on here. I verified that when bash.exe --login is launched /bin/bash does read from /etc/profile. I dumped my default /etc/profile and noticed a comment that:

# The default umask is now handled by pam_umask.
# See pam_umask(8) and /etc/login.defs.

When you run "bash.exe --login" that translates into "/bin/bash --login". We don't run the /bin/login binary and I'm assuming that's what normally sets up pam_umask. Did you try adding a new umask to value to your /etc/profile? It should work (when using bash.exe --login).

Yep, umask in both /etc/profile and ~/.profile run with both bash.exe --login and bash -c "bash --login".
Interestingly, if I revert the umask command and do bash.exe -c "sudo login" then umask is 0002 - no idea where that is coming from!

Please ensure umask is never 0000 no matter how bash is started.

I understand users can set umask to saner defaults in their own bashrc files but it means whatever directories and files auto-installed by scripts after WSL setup and user first bash run till the bad umask was discovered now have to be changed to sane defaults. This is exacerbated in git-based repos because git will track the change of perms to saner defaults as a (needless) change thereby status of git repo becomes dirty which simply put is both: confusing and annoying.

@0xMF don't worry, git only tracks +x, and the .bashrc changes are mentioned as a workaround

This also causes problems for zsh (compinit/compaudit). If you use a tool like antigen the directory permissions will throw shell errors when compinit/compaudit (command completion) is loaded.

Essentially any tool that performs basic checking for "other" write/read permissions will fail.

For anyone else trying to use dropbox, careful with symlinks to the windows /mnt/c/.... You'll likely run into a lot of problems. Unfortunately, dropbox for linux doesn't work yet either (because of the /proc/vmstat issue: #1071 ).

Hello, It's very strange. If I run ./configure, I found that the Makefile in the dir and sub dir only has permission rw no x. So some middle product didn't output, ./configure is right, but can't do make.

It's a big problem.

/usr/bin/m4: m4_esyscmd subprocess failed: Operation not permitted
/usr/bin/m4:configure.ac:489: cannot run command `./scripts/version.sh': Operation not permitted

I have put this in my ~/.profile in the meantime:

# Note: Bash on Windows does not currently apply umask properly.
if [ "$(umask)" = "0000" ]; then
>   umask 022
fi

@benhillis: if you have time to entertain my curiosity - is there a particular reason you don't run /bin/login?

@LilRed - good question. Historically there have been a couple of reasons. When we first released /bin/bash worked but other shells (zsh for example) didn't work very well and we didn't want users to set their default shell to something that didn't work and get into a bad state. There's also potential strangeness around running bash.exe and zsh being launched.

That being said, running login would actually make a lot of things simpler for us.  Currently our init daemon has to do many of the things that /bin/login normally does. We're doing some design for the next release of Windows and I'll take a look at this and see if it would make sense to potentially switch things over now.

If you'd like to play around with using login there's a way you can use it now.

lxrun.exe /setdefaultuser root
bash.exe -c "/bin/login -f username"

This is fantastic, thanks for the insight. I will change my Bash shortcut to this and report back if I hit any issues.

With /bin/login I do get umask returning 002, which is probably "good enough" to close this, but it's still not getting the "correct" default value 022 from /etc/login.defs line 151, which may be a thing.

Also it seems to start faster?!

One thing to be aware of is it doesn't extend PATH with the windows path.

@jackchammons Does closing this mean the default setup will now set a umask? /bin/login is not a default setup.

The current behavior is expected. We will be reevaluating where umask gets set in an future release.

This is breaking unit tests for swift-llbuild, part of the Swift.org project:

$ umask 22
$ umask
0022
$ mkdir foo
$ ls -l
drwxrwxrwx 2 root root 0 Mar 23 16:47 foo

Thanks for your patience. I'm adding a default umask of 022, with an /etc/wsl.conf setting to override it:

[filesystem]
umask = 02

Woo! My ls will finally be cured of it's horrifying green miasma!

Had a nice surprise today when I built a static site using Hugo in WSL from /mnt/d/ and saw that my published site had 777 permissions..

None of the workarounds mentioned here seem to have any effect. While it's possible to set umask to 022, everything is still created as 777 and worse, is immune to chmod!

Re-cloned the repo in my home folder and everything is behaving as expected there.

@radusuciu You probably won't ever be able to chmod stuff in /mnt/ drives. The permission models are completely different between Linux and Windows filesystems, so everything just appears as 777.

You probably won't ever be able to chmod stuff in /mnt/ drives

You've been able to do that since 17063 circa Christmas of 2017.

And the permissions stick? I'll have to play with that.

My workaround was:

• Start linux using: "wsl.exe -u root -- /bin/login -f username"
• Change /etc/passwd to use zsh: sudo usermod -s /bin/zsh username

Using that, default umask is set to 0002

If you want to use umask 022 you have two options:

• Set the variable "USERGROUPS_ENAB" to "no" in /etc/login.defs, and then use UMASK 022.
• Add umask 022 in /etc/profile or .bashrc

Ben's login(1) musing can fight another day a new issue/ask for wsl.exe --login or somesuch. This one deemed fixinbound last June with the umask configurable in wsl.conf. Applicable in both WSL1 and WSL2.

I just updated to 1909 and this problem is still there.

Confirming that with 1909 and a fresh install of Ubuntu. 000 is still the default umask.

This is how I workaround it in my dotfiles, if it helps anyone ;)

I just updated to 1909 and this problem is still there.

Right; it looks like Ben's fix shipped in 18945. 18945 > 18363 (aka 1909 aka 19H2). Which is to say, it appears a number of issues that were addressed in spring/summer 2019 never made it into the November 2019 Windows 10 release. [Or, at least on best evidence.] I'll bounce the tag on this one, but to be honest I'm hoping the fine-grained fixed-in tags die this spring in favour of whatever version is cited in the issue (presupposing they're cited). Here, 18945.

It seems that pam modules are (partly) still not functioning. MOTD is not correctly shown. #1966