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

mkdir command has wrong permissions #1801

Closed
hughbe opened this Issue Mar 23, 2017 · 18 comments

Comments

Projects
None yet
8 participants
@hughbe

hughbe commented Mar 23, 2017

  • A brief description

The default mkdir setting creates a folder with Read, Write, Execute permissions for Owner, Group and World (0777).
On other systems, mkdir creates a folder with Read, Write, Execute permissions for Owner and Read permissions for Group and World (0755).

This caused test failures running the https://github.com/apple/swift-llbuild project (part of Swift.org)

# command stderr:
/mnt/c/Users/hughb/Documents/GitHub-WSL/swift-llbuild/tests/BuildSystem/Build/mkdir.llbuild:15:22: error: expected string not found in input
# CHECK-PERMISSIONS: 0755
                     ^
/mnt/c/Users/hughb/Documents/GitHub-WSL/build/tests/BuildSystem/Build/Output/mkdir.llbuild.tmp.permissions:1:1: note: scanning from here
0777
^
  • Expected results

drwxr-xr-x 2 root root 0 Mar 23 16:35 foo

  • Actual results (with terminal output if applicable)

drwxrwxrwx 2 root root 0 Mar 23 16:35 foo

  • Your Windows build number

14393.953

  • Steps / All commands required to reproduce the error from a brand new installation

mkdir foo
ls -l

  • Strace of the failing command

N/A

  • Required packages and commands to install

N/A

@jakegt1

This comment has been minimized.

jakegt1 commented Mar 23, 2017

777 is the only default inside of windows directories when accessed through bash for windows.

It should work fine if you make a directory inside of WSL.

@hughbe

This comment has been minimized.

hughbe commented Mar 23, 2017

This is done through WSL.

Note: mkdir -m foo 755 foo also ignores the permissions and sets 777

@jakegt1

This comment has been minimized.

jakegt1 commented Mar 23, 2017

If you create a directory inside the windows file system (anywhere in /mnt/c etc), it will have 777 as the file permissions because it is actually using windows file permissions.

This is not a bug. If you redo the above inside of the WSL filesystem, you will create a directory as 755.

@futureproperty

This comment has been minimized.

futureproperty commented Mar 23, 2017

@jakegt1
it is also 777 in ~/ by bash.exe
see #1803

@hughbe

This comment has been minimized.

hughbe commented Mar 23, 2017

This is not a bug. If you redo the above inside of the WSL filesystem, you will create a directory as 755.

If you tried this, I'd be interested to see what differences our systems have

@jakegt1

This comment has been minimized.

jakegt1 commented Mar 23, 2017

Your example specifically shows you creating a directory inside the windows file system, you can't blame me on that one.

It seems it could actually be an issue though, I'd note that I've never noticed this happen to me so while i didn't actually go try it, directories i make inside of WSL seem to be fine.

It's probably something to do with how it creates directories outside of its own filesystem, anyway.

@jakegt1

This comment has been minimized.

jakegt1 commented Mar 23, 2017

Other than that, it could just be incorrect masks in respect to the issue, notably in the referenced but the creator states that the directory is '755' but it's '775', which is still non standard.

@aseering

This comment has been minimized.

Contributor

aseering commented Mar 24, 2017

The VolFs issue sounds to me like #352 . If so, the workaround would presumably be to manually set your umask to 0755, or something otherwise appropriate. If that works, this seems like a problem with that Swift test to me: While stock Ubuntu has a umask of 0755 (I think?), I have worked at a place (with a large network filesystem and many users) whose default configuration had a more-restrictive umask. WSL should strive to match stock Ubuntu's defaults, but Swift really oughtn't make assumptions about those defaults because they do get changed.

The DrvFs issue has been discussed on many tickets here, though at the moment I'm failing to find a single ticket to point at. No workaround at the moment, other than "use VolFs" :-) DrvFs simply doesn't implement permissions yet, so it exposes all files as world-writable and executable.

@hughbe

This comment has been minimized.

hughbe commented Mar 24, 2017

The default umask on Ubuntu is 0222 (http://askubuntu.com/questions/44542/what-is-umask-and-how-does-it-work)

Manually setting umask on the command line

Unfortunately, mkdir on WSL seems to ignore any umask you set:
mkdir-umask-set

umask 22
mkdir foo1
ls -l

Manually passing the mode on the command line

Unfortunately, mkdir on WSL seems to ignore any -m parameter you pass:
mkdir-mode

mkdir -m 755 foo2
ls -l
@aseering

This comment has been minimized.

Contributor

aseering commented Mar 24, 2017

@hughbe -- for the sake of clarity / future readers of this thread, could you please update your last post to note that you specifically tested DrvFs and not VolFs?

The behavior that you are illustrating is as expected per other discussion on this ticket.

@futureproperty

This comment has been minimized.

futureproperty commented Mar 24, 2017

@hughbe
how to explain mkdir is correct through ssh?(and don't ignore the -m)
And the umask is 002 defaualt through ssh,but mkdir creat a 755 folder.

@jakegt1

This comment has been minimized.

jakegt1 commented Mar 24, 2017

image
As i said in the first post, this is only an issue when you create a directory inside the windows file system, not inside WSL's own file system.

@hughbe

cd /home/a
mkdir myDir

Should give correct file permissions as set by umask.

Your example makes a directory inside the Windows file system (DrvFs), which does not support full linux permissions.

@aseering It seems that my umask by default was 0000, pretty sure i didn't set it. Should it be that by default?

@aseering

This comment has been minimized.

Contributor

aseering commented Mar 24, 2017

Hi @jakegt1 -- for VolFs and umask issues/discussion/explanation/questions, see #352 .

@jakegt1

This comment has been minimized.

jakegt1 commented Mar 24, 2017

@aseering I see, will keep it in mind.

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Nov 27, 2017

The OP here was about DrvFs which doesn't support umask by design (much like Samba shares and the like). umask does work on VolFs, though there is discussion about it not being set to people's liking on startup.

@jrcharney

This comment has been minimized.

jrcharney commented Jan 16, 2018

I think what everyone wants to know at this point is WHERE to set umask 022 so that WSL stops creating directories with 777 instead of 755.

The improper settings BREAK things like oh-my-zsh, antigen, and other zsh stuff.

An after-the-fact solution would be to run a compaudit then find $COMMON_PATH_OF_THOSE_DIRECTORIES -type d -exec chmod 0755 {} \;

Overall, it would be nice if WSL had the umask 022 mask enabled by default and simple "put that in [insert file name here]."

Because the next problem after that would be finding out why nice(5) denies permissions to do things. It could be for the same reason. (Follow up: It's issue #1887. Just need to add unsetopt BG_NICE near the beginning of ~/.zshrc.)

@gaibo

This comment has been minimized.

gaibo commented Mar 29, 2018

This thread was really confusing. It seems several people redirected here from other threads (though not OP) and I are experiencing the issue that even in /home/our_username, mkdir still makes with 777 permissions. umask returns 0000. Was there ever a clear answer to this @therealkenc ?

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Mar 29, 2018

Yeah there's a couple unrelated things going on here making it confusing. One is file permissions on DrvFs (/mnt/c), which are now supported in WSL as of Insider 17063 and Spring Creators real soon now. If the drive isn't mounted with the 'metadata' feature, directories are going to take on the permissions of the mount regardless of your umask.

The other is the default umask, which is still 0000 (causing a 777 mkdir). That is #352 and is still open. There are work-arounds over there, the easiest being to set the umask in your .profile/.bashrc/.zshrc/.whateverrc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment