Bug? umask does not seem to be respected

[twpayne]

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
0022
$ 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?

[Chuxel]

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.

[Chuxel]

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

[Chuxel]

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
user::rwx
group::r-x
other::rwx
default:user::rwx
default:group::rwx
default:other::rwx

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.

[Chuxel]

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.

[brettcannon]

FYI this umask behaviour breaks the CPython test suite. The above workaround fixes one test failure, but since this doesn't touch /tmp it didn't fix it for another (had to also run the above command for that second location).

[vin]

This has been causing us headaches as well; subdirectories created under /tmp end up with unexpected 756 permissions instead of 755. When our build process zips these up, those permissions get stored, and cause problems later when we end up with non-traversable directories. The root of this is the default:other::rw- below, which means that any subdirectories under /tmp get created with those other:rw- permissions.

codespace@codespaces-d61058:/workspaces/pants-perms-bug$ getfacl /tmp
getfacl: Removing leading '/' from absolute path names
# file: tmp
# owner: root
# group: root
# flags: --t
user::rwx
group::r-x
other::rwx
default:user::rwx
default:group::r-x
default:other::rw-