The UMASK variable is *documented* as affecting only the permissions for the initramfs image (which it doesn't seem to do reliably!) but it also affects the permissions for the files inside the initramfs.
>
When dropbear is used in the initramfs, the host private key must be kept secret and so the initramfs image must not be world-readable. But most of the files installed in the initramfs can be world-readable. Is that what you want to change?
No. I wasn't even aware that UMASK also affects the permission of files inside initramfs (as this is undocumented, as you said).
My setup is the following: Machine A with Debian boots from the network. Its /boot directory resides on machine B, which is simply a PXE server for machine A. /boot directory is mounted on machine A using sshfs. That way, on each update of machine A, kernel image and initramfs file are automatically transferred to machine B.
The problem is that tftpd on machine B has compiled-in limitation which allows only publicly readable files (o+r) to be served via TFTP.
Because dropbear package sets UMASK variable to 0077, (re)created initramfs file has no o+r permission. That means that it cannot be served by tftpd. So basically machine A won't boot on next reboot after update.
That's why I must override UMASK for (re)created initramfs.Another solution for my problem would be to retain permission of existing initramfs file during initramfs regeneration and use UMASK only when initramfs file does not exist.