My system has umask 027 set in shell sessions, including for the root user. If sys-kernel/gentoo-sources has been upgraded and built with genkernel, the files in /usr/src/linux/include/generated end up unreadable for the portage user. Emerging kernel modules (e.g. sys-fs/zfs-kmod) then fails. Steps to reproduce: 1. have gentoo-sources emerged 2. verify if umask is set to 027 3. run genkernel all 4. run emerge sys-fs/zfs sys-fs/zfs-kmod sys-fs/zfs-kmod fails with: ----- checking kernel source version... Not found configure: error: *** Cannot find UTS_RELEASE definition. ----- I have checked /var/tmp/portage/sys-fs/zfs-kmod-0.8.1/work/zfs-0.8.1/config.log but did not find any particular helpful message. After further research I found out that the error happens because the portage user cannot read header files in gentoo-sources. Therefore the configure run fails. For example, when running configure with additional debug settings it complains about the following file being unreadable: ----- # ls -la /usr/src/linux/include/generated/utsrelease.h -rw-r----- 1 root root 37 Sep 21 10:02 /usr/src/linux/include/generated/utsrelease.h ----- Apparently, genkernel does not ensure that file permissions within /usr/src/linux are properly set when a build is done. Which results in installation failures of ebuilds that need access to those files. The problem can either be fixed by running a recursive chmod over /usr/src/linux (not a preferred solution) or run make mrproper in /usr/src/linux, then manually set the umask to 022 and run genkernel again. I propose that a fix is applied to genkernel that ensures that permissions are properly set. Reproducible: Always Steps to Reproduce: set umask to 027 and run genkernel Actual Results: header files in /usr/src/linux are not readable for the portage user Expected Results: the portage user should be able to read the header files
Created attachment 590536 [details] emerge --info
To get this right: *You* are setting an umask value which will limit permission which will cause problems. You are now asking genkernel to set a proper umask value to prevent this?
This also happens on a manual build completely independent of genkernel, right?
emerge ensures builds complete in a predefined way, regardless of what the user was actually configuring in his environment. this also includes handling of permissions. I would expect genkernel to do the same. Yes, it also happens on a manual build. But after all, one of the reasons to use the build tools shipped by the Linux distribution is to ensure that builds are done in an environment agnostic way.
So what you'd like to see is each 3rd party kernel module ebuild check for sane permissions on /usr/src/linux during setup? Or you'd like it to SET sane permissions? I don't know that the ebuilds should be modifying permissions of files on the live system that the admin has already locked down perms on In any case, this surely is not a genkernel bug. I'm wondering where we should assign it.
Just some thoughts: Wouldn't it be possible to build the kernel in /var/tmp, using an unprivileged user? Most part of the build musn't be done as root anyway. All people having their /var/tmp in a tmpfs would also benefit. Or do it similarly as emerge does it: initialize a session as an unprivileged user with a well defined environment. The permission problem could also go the other way round, e.g. having a user accidentally set umask to 000 ends up with a system where unprivileged users can write the kernel sources and image in /boot. Or as you mentioned, ensure that the ebuilds somehow give out a better warning.
Yes, this is possible with genkernel-4 and we know about some user already using latest genkernel-4 in ebuilds for example. But keep in mind: When using another user to run genkernel, this user must still be able to write to (custom) kernel builddir including anything using that or building against that kernel. This includes your package manager: I.e. when using portage to install an additional module, the user running portage (well, user "portage" in most cases due to FEATURES=userpriv) would still require access to that builddir. So if you are using different users you will still run into problems with your umask 027... Your problem is: You have set system-wide umask which will cause problems if programs will honor this setting. You expect that tools will ignore this setting to avoid problems. This clashes with our view: I think that any tool, including genkernel, should respect umasks. I.e. I don't question user decisions. If you set something, I expect that you know what you are doing and have reasons. I am not going to alter your settings, i.e. forcing you to adjust settings of my tool to match your desired umask. tl;dr If you want special system-wide umask for some reason but not for genkernel, why don't you create a wrapper/alias which will call genkernel with different, non-problematic umask?
