Bug? umask does not seem to be respected

umask (which masks out file permissions) does not seem to be respected. This can be demonstrated by running the following in a Codespaces terminal:

$ umask
$ mkdir newdir
$ ls -ld newdir
drwxrwxrwx+ 2 vscode vscode 4096 Aug 29 10:25 newdir

Note that the permissions of newdir are drwxrwxrwx+ (0777). As the umask is 0022 the directory permissions should be 0755.

Is this behavior intended?

Just to double check - are you doing this locally in the Remote - Containers extension or in a Codespace? If Remote - Containers, on Windows, “bind mounts” all have those permissions due to how Docker works on that platform. This should not happen in a Codespace, however.

Thanks for the quick response!

I’m doing this in a Codespace (e.g. https://twpayne-chezmoi-h6q2.github.dev/), opening a terminal (e.g. Option-Backquote on macOS), and running the above commands in the terminal in the Codespace.

Another possibly relevant data point: I’m running as a non-root user.

Can you share the Dockerfile you used? It’s possible that there’s something in the image designed to do this for permissions purposes.

(new users are limited to two links per post so the following post is split)

Yes, I’m using the standard Go VSCode dev container sourced from here: https://github.com/microsoft/vscode-dev-containers/tree/master/containers/go
There is a minor modification to install an extra Go command, but that is all.

The Dockerfile is here: https://github.com/microsoft/vscode-dev-containers/blob/927b22006fa2c956c3653a2a8b7ba001aee9ca59/containers/go/.devcontainer/Dockerfile

(new users also get a limited posting rate, so I had to wait before being allowed to post the second part)

To duplicate the environment in which I observed the problem exactly, create a Codespace for the https://github.com/twpayne/chezmoi repo on the master branch.

The full .devcontainer directory is here: https://github.com/twpayne/chezmoi/tree/master/.devcontainer

Okay got it - I wasn’t repro’ing since I was creating a folder outside of the workspace folder.

What is going on is that the files in the workspace folder mounted from a mount point that is using an ACL that will set those permissions. If you go run mkdir ~/test, you’ll see that it is in fact getting the right privs. However, to see the privs for the ACL for the workspace folder, you’ll need the getacl tool. Install it as follows:

sudo apt-get update
sudo apt-get install acl

Then from the workspace folder run

getacl .

You’ll see this:

# file: .
# owner: root
# group: root

Is this causing a problem for you?

EDIT: There’s also a fix for this and things getting cloned as “root” coming soon. Both are related to the same problem.

Thank you for the detailed investigation!

The current behavior is a problem for me. My program checks file permissions and updates them if they are not correct, and I have a number of automated tests to ensure that this is working correctly. With the current behavior, as the file permissions are not being set to the requested values, the tests always fail.

I also noticed that in some cases creating a directory will cause the world-execute bit to be cleared (e.g. mkdir -m 755 newdir results in a directory with permissions 754, not 755) but although this happens consistently in some cases, I do not yet have a small test case to demonstrate it.

Great to hear that a fix for this is coming soon. It sounds like the best course of action for me is to simply wait for the fix. Is there a public issue that I can track?

We can provide an update here, but here’s a workaround for you near term.

  1. Go to the workspace root
  2. Run the following commands
sudo apt-get update
sudo apt-get install acl
sudo chown -R $(whoami) .
sudo setfacl -bnR .

That will remove the ACL and make sure you’re the owner of all files. At that point the umask should be respected.

1 Like

That works, thank you for the fast and helpful support :slight_smile:

1 Like