BB_DEFAULT_UMASK leaks into generated rootfs

BB_DEFAULT_UMASK leaks into generated rootfs

[Rasmus Villemoes]

Hello

After setting BB_DEFAULT_UMASK = "002", we started getting

  sshd-session[1965]: error: Unsafe AuthorizedKeysCommand "/usr/bin/userdbctl": bad ownership or modes for directory /

on target. And true enough, the permissions of / are

# ls -ld /
drwxrwxr-x 15 root root 221 Apr  5  2011 /

A somewhat odd oberservation is that while the umask setting does make
various aux directories under ${WORKDIR} have the expected 0775
permissions, the directory 'rootfs' itself does not have write
permission for group:

  $ ls -ld deploy-source-date-epoch/ recipe-sysroot-native/ rootfs/ temp/
  drwxrwxr-x  2 ravi ravi  4096 Jun  4 14:42 deploy-source-date-epoch/
  drwxrwxr-x 12 ravi ravi  4096 Jun  4 14:42 recipe-sysroot-native/
  drwxr-xr-x 15 ravi ravi  4096 Mar  9  2018 rootfs/
  drwxrwxr-x  4 ravi ravi 12288 Jun  4 14:43 temp/

However, both the generated tar-ball and squashfs images have recorded
that 0775 mode for the root entry:

  $ tar tvf deploy-pil-rootfs-image-complete/pil-rootfs-rpi4.tar |head -n1
  drwxrwxr-x 0/0               0 2018-03-09 13:34 ./
  $ unsquashfs -lls deploy-pil-rootfs-image-complete/pil-rootfs-rpi4.squashfs | head -n1
  drwxrwxr-x root/root               221 2018-03-09 13:34 squashfs-root

so I assume that must come from the pseudo database.

And the problem seems to be much bigger than just / having wrong
permissions. We also have /etc/passwd being

  # ls -l /etc/passwd
  -rw-rw-r-- 1 root root 1060 Apr  5  2011 /etc/passwd

Other files/directories being affected include /usr/lib/clock-epoch,
/usr/share/common-licenses/ (but not any of the files in there), and all
the xml files, but not directories, under /usr/share/mime/.

Rasmus