shfs: Is there a way to have the ebuild error if FEATURES includes userpriv as I have umask set to 027 and make my kernels as root so the /usr/src/linux/.config file is not readable which causes emerge to fail. (among other permission denied errors) nvidia-kernel: *** Unable to determine the target kernel version. *** Which is most likely the same issue as above wrapped in a 'pretty' nvidia message. There could be others too but these are the only ones I've noticed so far.
Well, with tweaking your umask, your are really on your own. If it's not readable, then it's not readable. ;)
arg i just hit this junk ... wonder if doing RESTRICT=userpriv for kernel modules is out of the question ?
I'm not so keen on the idea as apparently userpriv works just fine with kernel modules, it's only when you mess with umask it breaks, right? However, if you think it is important/worthwhile then I wouldn't object.
it isnt really a umask issue if you run `chown -R go-rwx /usr/src/linux`, things break with userpriv enabled
*** Bug 150837 has been marked as a duplicate of this bug. ***
So based on the determinations in this bug, this is an invalid bug report since the umask tweakings make files unreadable. Also file privileges on the kernel are insufficient. So all in all it's a user-side configuration issue. The argument for a warning should be taken up with the Portage guys.
kernel modules are all handled via the linux-mod.eclass so any warning should go in there, not portage
So if it's a linux-mod.eclass tweak that needs to happen, that's the kernel herd. Not x11-drivers.
*** Bug 210135 has been marked as a duplicate of this bug. ***
so what do people suggest happens here? An ewarn in linux-info.eclass? Unconditional? or something completely different?
How about an error message that's conditional on /usr/src/linux/.config being unreadable? If there's no hope of success then you should die immediately in that case.
that sounds reasonable to me ... dieing with an informative message is better than random compile failure perhaps recommend they run: find ${KERNEL_DIR} -type d -print0 | xargs -0 chmod a+rx find ${KERNEL_DIR} -type f -print0 | xargs -0 chmod a+r
Closing bug as both packages aren't in our tree anymore.
Is this bug still valid? If yes, please correct Title, otherwise I will close the bug again the next days.
Hardened users are likely to hit this in the future with GRKERNSEC_HIDESYM enabled.
Can we detect an existing but non-readable /usr/src/linux and $KBUILD_OUTPUT easily? Then we can trigger die statements for them under linux-mod (require_configured_kernel actually).
Seems this bug is still hanging around. # touch me && ls -al me -rw-r--r-- 1 root root 0 Mar 7 17:49 me # umask -p umask 0022 And yet, /usr/src/linux/.config is created with the following permissions. # ls -alh /usr/src/linux/.config -rw------- 1 root root 87K Feb 20 00:41 /usr/src/linux/.config Using FEATURES=userpriv seems to break kernel module ebuilds here too (for a long long time). As such, just been using -userpriv for the past year(s). See Bug #388049
Now that userpriv seems to have been enabled by default, modules fail to build. Telling users to just "change their umask" sounds a bit silly, if portage wants to offer a feature where packages are built as portage:portage, it should somehow make sure that files needed to build other packages are accessible by portage:portage. We already install binaries with permissions that override the umask, why not do the same with /usr/src/linux*?
Finally having another look at this, the problem persists due to several additional files which are required to build external modules, but which are generated by the kernel build process. There is likely no easy solution except chmodding the source tree every time a new kernel is compiled or building the kernel as portage:portage. For now, maybe the best thing for an user to do is to disable userpriv for out-of-tree kernel modules and other packages requiring read access to /usr/src/linux. Either that or maybe I'll add chmod to the chain of commands I use to compile the kernel. A warning is perhaps the best way to deal with this situation, as I doubt chown'ing/chmod'ing files automatically is a good idea.
According to my Comment #17, I was using "-userpriv" at one point. But on my recent 64 bit install of Gentoo, I seem to be doing just fine without specifying "userpriv" or "-userpriv" within the /etc/make.conf. And my "emerge --info" shows the "userpriv" as on/active by default I believe my Comment #17 was performed on a 32 bit platform. On my 64 bit platform here everything within my /usr/src/linux seems to be readable by everyone now. (Or, I hacked in a chmod/umask solution somewhere and now I can't recall it. ;-) If I'm not mistaken, this bug is encountered when trying to build module packages (ie. nvidia-drivers) requiring read access to the /usr/src/linux/.config file. Since this file was marked as only readable by root (and likely all other build files per the previous comments here), installing modules would only have portage.portage permissions and hence, not being able to read /usr/src/linux/.config file. The build process would also only display a cryptic message of "Unable to determine kernel version". Checking for the existence of the /usr/src/linux/.config file, then checking for proper permissions would probably be a good idea someplace. But I have not traced the emerge permissions processes. If this bug is continued to be encountered, take note of the EBUILD file and institute a fix of checking for the existence of the files and proper permissions prior to issuing make?
Gentoo uses an umask of 0022 by default, so new installs won't have the problem unless you do explicitly change the umask. The problem goes beyond .config: files generated by the kernel build process will be read by some of these ebuilds (for example, broadcom-sta).
As of =sys-apps/portage-2.2.7, I've finally run into this bug again just today for the first time on this amd64 platform! While compiling =app-emulation/virtualbox-modules4.2.18: I first encountered: /usr/src/linux/include/generated/autoconf.h Permission denied # chmod -R a+rX /usr/src/linux && emerge -q =app-emulation/virtualbox-modules4.2.18 /bin/sh: scripts/genksyms/genksyms: Permission denied Finally the following solves all problems: FEATURES="-userpriv" emerge -q app-emulation/virtualbox-modules
FEATURES="userpriv" emerge -q app-emulation/virtualbox-modules * IMPORTANT: 3 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. >>> Verifying ebuild manifests >>> Emerging (1 of 2) virtual/linux-sources-3-r5::gentoo >>> Installing (1 of 2) virtual/linux-sources-3-r5::gentoo >>> Emerging (2 of 2) app-emulation/virtualbox-modules-6.1.22::gentoo >>> Installing (2 of 2) app-emulation/virtualbox-modules-6.1.22::gentoo >>> Recording app-emulation/virtualbox-modules in "world" favorites file... * IMPORTANT: 3 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. No issue here. Please re-open if I am misinterpreting how to test this.
Mike, what are the permissions of your /usr/src/linux/.config? What is your umask when you configure and compile the kernel?
I think this is more of a CANTFIX than a WORKSFORME. If the permissions under /usr/src/linux are too restrictive, this will obviously conflict with a build process running as the portage user. A few people suggested that we attempt to detect this earlier somehow, but nobody has submitted a patch to make that happen in the last 15 years. Proposals are always welcome via the gentoo-dev mailing list.
