Yocto suddenly creating directories with 700 instead 755.

["Manuel Wagesreither" <ManWag@FastMail.FM>]

Hello all,

sorry, wall of text incoming.

tl;dr:
If recipes install directories with `install -d path/to/dir`, how is the default mode determined? What can cause it suddenly (that is, without updating metalayers or similar) to change from 755 to 700?


full version:

our CI is throwing "Transaction check errors" of the following form:

```
file /etc conflicts between attempted installs of redactedone-appconfig-1.0-r0.aarch64 and modemmanager-1.12.12-r0.aarch64
file /etc conflicts between attempted installs of tegra-configs-udev-32.4.3-r0.armv8a_tegra and redactedone-appconfig-1.0-r0.aarch64
file /usr conflicts between attempted installs of redactedtwo-scripts-1.0-r0.aarch64 and nvidia-docker-2.2.2-r0.aarch64
file /usr/bin conflicts between attempted installs of redactedtwo-scripts-1.0-r0.aarch64 and nvidia-docker-2.2.2-r0.aarch64
file /usr conflicts between attempted installs of iptables-dev-1.8.4-r0.aarch64 and redactedtwo-scripts-1.0-r0.aarch64
file /usr/bin conflicts between attempted installs of systemd-1:244.5-r0.aarch64 and redactedtwo-scripts-1.0-r0.aarch64
```

I examined/unpacked the .rpms in tmp/work/deploy/rpm/aarch64 and really, they do differ in the mode bits for /etc, /usr and /usr/bin. While these dirs have a mode of 755 in poky/oe packages, they have a mode of 700 in our packages. The puzzling thing is that this issue has arised only recently with a totally independent change in some recipe not mentioned above. The change consisted of changing the URI of a tarball we fetch from AWS S3 and using sha256 instead md5 for checksumming the file.

At first, this issue appeared somewhat reproducible, but I think that was just coincedence. Perhaps there is some cache poisoning at play here. Now builds are also failling which don't have this "bad" commit. Tests are still going on. I'm now testing if deleting the tmp dir changes anything.

So this mail is rather about: Do you know anything which can point me into the right direction? The recipes in question all install the directories with `install -d ${D}/somedir`. I changed some recipes to have `-m 0755` as well, and one build did indeed succeed then, but then builds started to fail with the same symptoms but other packages being the culprit, that is, having the dirs with 700.

I heard the default mode of files/dirs in unix is set with umask, but I have no idea how to check if/how Yocto is fiddling with that.

Also, sometimes we have these errors: They seem to go away with cleaning the tmp dir, while the errors above persist. But the sample size is very small so that might be a wrong lead.

```
INFO     - NOTE: Running task 12010 of 12044 (/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs)
INFO     - NOTE: recipe our-image-1.0-r0: task do_rootfs: Started
ERROR    - ERROR: Task (/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs) failed with exit code '134'
INFO     - NOTE: Tasks Summary: Attempted 12034 tasks of which 12001 didn't need to be rerun and 1 failed.
INFO     -
INFO     - Summary: 1 task failed:
INFO     - /opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs
ERROR    - Command "/opt/buildagent/work/77acccee8c88a2cf/build$ /opt/buildagent/work/77acccee8c88a2cf/poky/bitbake/bin/bitbake -c build our-image" failed
--- Error summary ---
ERROR: Task (/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs) failed with exit code '134'
```
Google said exit code 134 means the process received a SIGABRT, but... I'm quite sure no-one sent one.


Thank you all,
regards,
Manuel