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

Default umask (permissions) is not applied #352

Open
simonbuchan opened this issue May 12, 2016 · 30 comments
Assignees

Comments

@simonbuchan
Copy link

@simonbuchan simonbuchan commented May 12, 2016

Reference: http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html

My current install has this in /etc/profile:

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

And, indeed /etc/profile has UMASK> > 022, but:

simon@QOF:~$ umask
0000

The effect of this is that new files are created with 666 and dirs with 777 permissions:

simon@QOF:~$ touch file
simon@QOF:~$ mkdir dir
simon@QOF:~$ ll -d file dir
drwxrwxrwx 2 simon simon 0 May 12 22:54 dir/
-rw-rw-rw- 1 simon simon 0 May 12 22:54 file

This mostly isn't a real problem since UoW doesn't have to care about multiple users, it largely shows up as ls showing dirs with an ugly green background, but it could freak out some tools, similar to ssh wanting 600 on your private keys.

Simplest fix would probably be to dump a umask 022 in /etc/profile, but it seems there's a bunch of stuff in that /etc/login.defs

Easy workaound is to add a umask to your ~/.bashrc

@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented May 13, 2016

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

@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented May 13, 2016

@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).

@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented May 13, 2016

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!

@0xMF

This comment has been minimized.

Copy link

@0xMF 0xMF commented May 26, 2016

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.

@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented May 26, 2016

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

@neurogenesis

This comment has been minimized.

Copy link

@neurogenesis neurogenesis commented Oct 16, 2016

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 ).

This was referenced Oct 16, 2016
@zhangxj5

This comment has been minimized.

Copy link

@zhangxj5 zhangxj5 commented Oct 23, 2016

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.

@zhangxj5

This comment has been minimized.

Copy link

@zhangxj5 zhangxj5 commented Oct 24, 2016

/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

@lilred

This comment has been minimized.

Copy link

@lilred lilred commented Dec 1, 2016

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?

@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Dec 1, 2016

@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"

@lilred

This comment has been minimized.

Copy link

@lilred lilred commented Dec 1, 2016

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

@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented Dec 1, 2016

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?!

@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented Dec 1, 2016

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

@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented Feb 15, 2017

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

@jackchammons

This comment has been minimized.

Copy link
Member

@jackchammons jackchammons commented Feb 15, 2017

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

@hughbe

This comment has been minimized.

Copy link

@hughbe hughbe commented Mar 23, 2017

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

@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented Jul 15, 2018

I'm happy with anything from #352 (comment) (well, not happy with by design, but I get it)

The feature would be either implementing this one thing that real init does in some way, or switch to using real init somehow.

tikkss added a commit to tikkss/dotfiles that referenced this issue Aug 16, 2018
/etc/wsl.conf に umount の設定をしても、 WSL の umount
の設定には反映されない不具合がある。

マウントされた Windowsのフォルダやファイルの umount 設定は正常である。

回避策として、WSL 独自の config.fish に umount 設定を追加した。

microsoft/WSL#352
PhilipDaniels pushed a commit to PhilipDaniels/dotfiles that referenced this issue Aug 21, 2018
See bug microsoft/WSL#352 about umask
not being set (it is 0000) which results in directories having
ugo+rwx permissions which then results in ugly directory listings.
kodemeister added a commit to kodemeister/prezto that referenced this issue Sep 20, 2018
@sjackman

This comment has been minimized.

Copy link

@sjackman sjackman commented Nov 2, 2018

This issue is causing trouble when running the Linuxbrew/Homebrew package manager in WSL. I'd love to see the default umask set to 002.

@27Bslash6

This comment has been minimized.

Copy link

@27Bslash6 27Bslash6 commented Mar 8, 2019

This is still a thing? Is 3 years not long enough to arrive at a conclusion to this issue?

kodemeister added a commit to kodemeister/prezto that referenced this issue Apr 19, 2019
Alex-D added a commit to Alex-D/dotfiles that referenced this issue Jun 5, 2019
see microsoft/WSL#352 for details
karolyi added a commit to karolyi/anaconda that referenced this issue Jun 10, 2019
Hey,

on the latest windows WSL update, the created socket file gets a 0o000 permission regardless of the current umask. I managed to reproduce it in Python and this seems to be the fix for it.

Also might be related to microsoft/WSL#352
@benhillis

This comment has been minimized.

Copy link
Member

@benhillis benhillis commented Jun 27, 2019

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

[filesystem]
umask = 02
@benhillis benhillis self-assigned this Jun 27, 2019
@simonbuchan

This comment has been minimized.

Copy link
Author

@simonbuchan simonbuchan commented Jun 28, 2019

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

@radusuciu

This comment has been minimized.

Copy link

@radusuciu radusuciu commented Oct 25, 2019

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.

@dgw

This comment has been minimized.

Copy link

@dgw dgw commented Oct 25, 2019

@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.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

@therealkenc therealkenc commented Oct 26, 2019

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.

image

@dgw

This comment has been minimized.

Copy link

@dgw dgw commented Oct 26, 2019

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

yous added a commit to yous/dotfiles that referenced this issue Nov 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.