Building the kernel as root can be harmful

[nicop06]

I recently came across this video from Greg Kroah-Hartman where he pointed out a bug in the kernel build that would completely delete /. I double checked in the Gentoo wiki about kernel configuration and genkernel and it is clearly indicated to build it as root.

I know what some could say: if you don't want to build it as root, don't do it. This is not my point. I for one perform hourly BTRFS snapshots of my system, so I can recover a complete wipe out of my root partition in minutes.

I was wondering if there ever was a discussion about using the sandboxing mechanism of portage (for instance) to build the Kernel, at least when using genkernel. Among all the Linux distribution I have used (I insist on Linux, as that's not the case on BSD), Gentoo is the only one building the kernel differently.

I myself enjoy the fact that the kernel is directly present in /usr/src to quickly change kernel configuration (I don't even use genkernel). But doing for instance

[Ant P.]

The kernel supports out-of-tree builds:

[i92guboj]

Thankfully, Gentoo has ways to deal with this idiotic default.

The first thing I ever do in a new install is

[Anon-E-moose]

[i92guboj]

[Hu]

To go one step further, you can set $INSTALL_PATH and $INSTALL_MOD_PATH prior to running make install / make modules_install to get approximately the same effect as $DESTDIR on autotools packages. This lets an unprivileged user install to a staging area, which root then copies to the live filesystem. This can be convenient if you build one kernel for several machines.

[josephg]

gentoo was the first distro officially asking users to kernel compile as root. i have used many other distros, and recommendation has always been to compile kernel as normal user. thanks for this thread.

[jonathan183]

There are a number of ways to avoid building the kernel as root, my approach is to have a kernel_builder user and chown the /usr/src/linux tree to that user and then build the kernel, I do this at install stage and then just continue this method while maintaining the system. I think it would be good to include a non-root method of building the kernel in the handbook and encourage users to take that approach. I don't know which method would be the best ... but I guess most would be better than building the kernel as root.

[tld]

Interesting...this whole topic is news to me. I've always done this as part of my updates as root.

[krinn]

bah, you're paranoid for me, everything could be harmful, the kernel is not made to delete / but a bug could had done that.
if you're scary about shit happening, use backup, but if you start sandboxing kernel because build could have a bug in it, you'll sandbox every tools you could use, because, a bug is not a feature, and all tools could have one.

at end, you have secure everything with sandbox, to see a sandbox bug deleting all your datas

i'm not saying nobody shouldn't take a bit of care, specially when root, but you have to trust the tools a bit, the time you lost in taking care of everything would be better invest in backing up your datas.

there's also something odd there: if i lost root, i'm good for a reinstall, bah, time lost on reconfiguring everything etc... but if i lost my home, i'll lost my datas that i care for, hence i find odd someone prefer using a user.

[Hu]

A dedicated kernel build user can protect the user's regular data. A build bug that deletes / would likely also delete all user home directories.

Clever use of namespaces to isolate the build system so it cannot modify outside its intended area can also mitigate such problems.

[ct85711]

I agree with krinn as you need to trust something; as anything can have a bug in it that could destroy everything. In the end, running as root is always dangerous hence why it is recommended to use root only when it is necessary.

Either way, it is better to keep backups (the more important stuff have multiple backup copies) so you can recover when something happens. In the end, one of the more common sources of problems is what is behind the keyboard (which I would love to see a patch to fix that )

[Ant P.]

[krinn]

i would (which i'm not doing) prefer just remount /home ro while building a kernel to prevent it from getting harm.

gkh article is about : hey don't trust us blindly as we can harm your system too ; but it's something you are force to do everyday else you'll loose a lot of time.

you take back your car from garage ; you don't remove all parts of the car to check what has been done
you drop a letter in the letterbox, you don't take a plane to follow the letter
you put your paycheck to the bank, you're not checking all the guys to see if one will steal your money

sure you can follow the letter or check your account if your money is there, but it's a check if something bad has happen, not a check if something bad will happen.
because if one would do that, it would really be better to check the car, as you might endup in a wall to figure out you shouldn't had trust him, but really, who do that?

so, you just build your kernel as root, and you suppose nobody is trying to harm you

[jonathan183]

[nicop06]

Thank you for all those interesting replies. As I explained, I am paranoid about backup, which paid of as I've used them multiple time. I encourage everyone to do the same (a simple rsync crontab takes 5 minutes to setup). My main problem was about documentation, especially for new comers.

I myself recently switched to Gentoo 2 years ago and with that started to build the kernel. At the time I never questioned the handbook. After hearing this remark from GKH, I realized how contradictory Gentoo is concerning packages.

In Arch (or Alpine, or Void), all packages are built without any sandbox as regular user, including the kernel. In Gentoo, all the builds are sandboxed except the kernel which is built as root, and there should be a middle ground. I know, I can't imagine any kernel developer purposely adding code to harm your system when you build it as root (they can do it in much more subtle ways if they modify the kernel core part). But Linux has a large code base and as anyone knows bugs are unavoidable and hard to predict in that case.

I think there should be more information about building the kernel as a regular user. Your suggestions about out of tree build or using a kernel build user are exactly what I had in mind when I wrote the post and may be added to the wiki. Also, as it has been pointed out, current model where some packages read /usr/src/linux can be improved. Maybe we can install kernel headers to build other packages instead of reading them in the source, and maybe read the config from /boot (or other places).

I mainly wanted some opinion to see if it was worth opening an issue to Gentoo DEV to see how it can be improved. My point being, if it's something we should all do and it's not enforced or encouraged by the distribution nobody will do it.

By the way, anyone noticed the bug described by GKH? It might be really old , I am just asking out of curiosity.

[krinn]

[ct85711]

One part you are going need to keep an eye on, is that other packages do compile against the kernel sources too. Those emerge processes are sandboxed, so may not have the privilages to access the compiled files...

As far as documenting about this, think about what all you had to do to compile the kernel sources as a user (non-root). Most of those steps would have to be completely redone each time you get a new kernel source; as portage just downloads the new kernel sources into their own folder seperate from other kernel sources (/usr/src/linux is just a sym link to the selected kernel's folder).

[nicop06]

[jonathan183]

[i92guboj]

[Hu]

I find the use of $INSTALL_PATH / $INSTALL_MOD_PATH to be simpler and more reliable than trying to track down all the files installed by make install modules_install as root. I consider the rise of $DESTDIR and equivalent in other build systems to be evidence that other people likewise prefer to install to a clean staging area and record its state rather than install directly into the live environment and try to guess the state afterward. This approach also has the benefits that there is no need to chown anything before building and that you can review exactly what will be installed using standard directory tools. As mentioned previously, this is also very helpful if the kernel is built on one machine, then installed on a different one.

The only drawback I see to an out-of-source build like this is that, as mentioned by ct85711, many packages expect to dig around in a prepared /usr/src/linux to guess what state the running kernel will have. I find this approach to be well-intentioned, but frequently counterproductive. It is a concern for some users, and would need to be mentioned as a caution for any instructions on out-of-tree builds.

[i92guboj]

There's nothing to track down. Kernel goes into /usr/src/linux. Modules goes into /usr/lib/modules

You can hack all you want. But, at the end of the day, rm is all you need.

[Jaglover]

I used to download sources to my home and build the kernel as user when I was running Debian, then copied it over as root. It is a little more complicated with Gentoo if you want to apply gentoo-patches. Still no rocket science.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[jonathan183]