I'd certainly expect .config to be owned by root, else replacing this file with something else could be dangerous if a user were to need to rebuild a kernel without needing modifications, as I myself have had to do often.

So now I have to figure out what to do about the headers. The problem appears to be that they're there but in the wrong place.

This is turning into a flamewar, isn't it? Do as you like on your system. But, do take a second and look at the permissions of the kernel source modules. It seems they're not root either. Hmmm.

I was thinking that there hasn't been any flaming yet; but if there is any, it won't involve me--the question of whether the kernel source modules are root hasn't struck me as very important. It so happens that I need to hold off on this project anyway, because in case it ultimately doesn't work, I have bought another hard drive, an IDE, and will be busy reinstalling MEPIS on it. (Then I'll start this kernel compiling all over again. Maybe the new installation will have the kernel headers where they're supposed to be, anyway.)

So maybe I should duck out of my own thread now.

If sometimes happens that we need to do a reinstall; especially for the newer users. I'm reaching that point with my system, I think. I've got an issue with playing .flv files and I'm not making any progress at all.

It sounds like you're starting to get an understanding of the procedures to follow to build a new kernel. I would expect that you will be fine once you do the reinstall.

Wow, I only meant to say that on the ideal system, everything to do with the kernel, config or not, would be root based; its certainly nothing to do with you; you had nothing to do with the design. A flame war seems very extreme.

@newbiesforever: Kernel sources are immaterial here- the original error is from the kernel sources trying to use headers which aren't in whatever the equivalent to $PATH is for C- try writing and compiling some C with a couple of those headers being loaded- see if they load; if they do, its the kernel source, if not, its a gcc error- in which case, gcc wants rebuilding.

Unfortunately, this would add still another temptation for people to just login to root and have done with it, thus having done with one of the inherently strong protections that Linux affords. The risk that someone will write a worm/virus/malware that will login as you and then search out source code modules to modify on the offhand chance that you will then compile a new kernel with the bad code and install it has to be much lower than the risk of teaching users to use root casually.

From my POV, the current system is good. You can put your kernel source wherever you like, and you can mess with the source and .config files to your heart's content as a normal user. It's only when you need to install a new kernel that you need to become root.

(I have now got my new IDE hard drive, bought in case the SATA drive never works, up and running, with a new copy of MEPIS, and can continue this project.)

I just had a discouraging thought. Here I am with MEPIS on an IDE drive, trying to recompile its kernel for a SATA HD (obviously since the SATA device hasn't been detected yet by MEPIS). But why am I doing that? Until I discovered that this SATA HD didn't work and had to buy another new drive (that was IDE) this SATA HD was going to be my main hard drive. So basically, I don't really want the SATA drive to be detected from an IDE drive; I want the SATA drive to detect itself (through MEPIS). So isn't what I'm doing pointless? Unless I'm willing to use the SATA drive only as a backup drive?

Oh, well. At least my new IDE drive works fine, so I can send the SATA drive back to Newegg (or at least try).