Intermediate dirs created for bind mounts have a too restrictive umask

[vidraj]

When binding a file from the host file system into the chroot, bubblewrap helpfully creates all intermediate directories that don't exist in the target. However, cross-boss uses a restrictive umask. As a result, those dirs get created with permission 700, owned by root:root.

Since the binds are typically executables, this causes them to only be executable by root – other users won't be able to read them even though the permissions of the file itself are fine. If the executable in question is an ELF interpreter such as qemu-user, it causes any execve of a target-arch ELF to fail with EACCES, with no other explanation, resulting in an issue that's difficult to diagnose. :-)

Is it possible to

1. disallow creating intermediate directories and failing, forcing the user to create them manually with correct permissions, or
2. change the umask to 755 or similar, or
3. document the issue and add a record to the FAQ?

[chewi]

What makes you think it uses a restrictive umask? umask and mode are not the same thing. umask 022 is equivalent to mode 755.

[vidraj]

I mean umask in the general sense of creating the directories with insufficient permissions. I'm not sure what mechanism causes it, but the documentation of bubblewrap explicitly says that directories get created with mode 755 unless you do something to change that.

[vidraj]

I see that I used the term umask incorrectly in point 2, apologies. :-)

[chewi]

I see. These directories are created by bubblewrap though, and we don't have any control over the mode, short of creating them in advance. We could do that, but where are you seeing this in practise? I would expect all the directories that cb-bwrap binds to already exist by the time it gets called.

[vidraj]

I see this with the QEMU binaries if they are installed into e.g. /usr/local/bin, which would not ordinarily exist in the target FS unless some native software was installed there first.

Creating the dirs in advance and possibly copying their permissions from the host FS is another option, yes.

As far as I understand the problem, the paths must be the same inside the chroot as they are outside, because otherwise binfmt_misc would break, so that's a constraint – otherwise the cleanest solution would be to place each required binary into a special temporary dir and delete them after exiting the chroot (that's another papercut with the current solution – the empty dirs and empty files remain in the target FS).

It's generally a minor issue, the biggest problem for me was debugging why I couldn't execute anything in cb-bwrap as a non-root user.

[chewi]

I could put a line in bwrap-common.sh to make the directories, although it would have to be run as root the first time.

I'm wondering why your QEMU is in /usr/local/bin. Did app-emulation/qemu[static-user] not meet your needs?

[chewi]

Ah, that was for the wrapper you mentioned in #2?

[vidraj]

I'm wondering why your QEMU is in /usr/local/bin. Did app-emulation/qemu[static-user] not meet your needs?

It generally does, but I also use a custom patched QEMU for PA-RISC. I don't patch via Gentoo userpatches, because I also need to have one QEMU that works, so I keep two (or more) parallel installations.