Why emerge -depclean want to remove the inuse kernel source?

[E001754]

All,

All is in the title?
Why shall emerge --depclean wants to remove the in use kernel ?

I have the current kernel 3.2.1-gentoo-r2.
The newest one is 3.2.12.


On running emerge --depclean, emerge wants to remove 3.2.1 that I'm currently using, and keep the 3.2.12 that I don't use (and to plan to use).

Could --depclean become smarter and don't flag for remove the currently used kernel sources ?

Of course, a simplest workaround is to manually remove 3.2.12 than run again --depclean, but I'm sure this step could be avoided easily.

Or is there some weird reason for not doing that default on --depclean?
Where else shall I post this feature request so that some dev can hear at that?

[asturm]

emerge has no knowledge about what kernel currently is in use. However, since the kernel sources are not actually 'in use' once the image and modules have been built, they can safely be removed and emerge --depclean will always keep the latest version.

[steveL]

Could --depclean become smarter and don't flag for remove the currently used kernel sources ?

It could but it's more code to write and maintain, and it needs to be justified.

Or is there some weird reason for not doing that default on --depclean?

Technically it's the correct thing: as genstorm said, you don't need the package installed on your system for anything (it's just been pulled in as part of world.) Each version has its own SLOT, and in portage's eyes, you only need the latest one to satisfy the world dep on whichever source package you went for (so if you did: emerge gentoo-sources, the package is in world, not every SLOT.)

I recommend a review of /var/lib/portage/world every few months, btw, as it's useful to clean it up occasionally. If you still want everything in there, no probs. But if you don't (it's amazing how often there's things in there I've forgotten about, and don't use) just get rid of it: if it's needed by something else, --depclean won't remove it.

Where else shall I post this feature request so that some dev can hear at that?

Not sure if it'll get you anywhere: I had the same discussion years ago, and ended up putting the functionality into update -C.* So it protects the running kernel, and the /usr/src/linux linked package if that's not the same: if you have symlink USE flag (iirc it's default, but I turned it off years ago because of this issue), then when you upgrade it updates the link automatically. This can be a pita if you later compile something against the kernel, as it won't be the one you're actually using.

*The --depclean wrapper part of [topic=546828]update[/topic], which runs automatically (after the whole run, if there's no problems, but before revdep-rebuild) if you're doing the standard -uDN world, which is the default if there's no target given on the command-line.

[John R. Graham]

I wouldn't object to --depclean being smarter, but there is a simple, effective workaround. You know when you build and test a new kernel. As part of that process, always add it to the world set. For example, in your case:

Code: Select all

emerge --noreplace =gentoo-sources-3.2.1-gentoo-r2

When you're finally done with that kernel (you'll unambiguously know this, too):

Code: Select all

emerge --deselect =gentoo-sources-3.2.1-gentoo-r2

I agree with steveL on the symlink USE flag: turn it off.

- John

[i92guboj]

What I particularly do is to add gentoo-sources to package.provided, then download the latest stable from kernel.org to my home directory, where I can build the kernel without being root (still don't know why would I need to be root just to compile a kernel...). I set /usr/src/linux to /home/i92guboj/kernel/linux, being that also a symlink, to whatever kernel I want at a given moment (there are lots of them in /home/i92guboj/kernel/.

I just need to su to make install modules_install, which is saner.

[depontius]

If you have actually built the kernel source, "emerge --depclean" doesn't actually remove it. It only removes untouched source.

[John R. Graham]

Actually, that turns out not to be the case. Emerge will remove any unmodified file that it installed. That means that a --depclean will remove all of the kernel source but none of the work products. All of the build cruft (principally .o files) will be left but the kernel source will be gone. It is true that the installed kernel binaries (in /boot and /lib/modules) will not be touched.

- John

[E001754]

I wouldn't object to --depclean being smarter, but there is a simple, effective workaround. You know when you build and test a new kernel. As part of that process, always add it to the world set. For example, in your case:

Code: Select all

emerge --noreplace =gentoo-sources-3.2.1-gentoo-r2

When you're finally done with that kernel (you'll unambiguously know this, too):

Code: Select all

emerge --deselect =gentoo-sources-3.2.1-gentoo-r2

I agree with steveL on the symlink USE flag: turn it off.

- John

This is one good trick.

In fact, i'm just keeping the kernel sources as the sources can disappear from the tree without warning and I have in mind that I need the sources to be able to compile some packages, especially ati-drivers.
I also won't be forced to switch to a newer kernel as switching to a newer kernel can sometimes be a pain.

I never switched the USE flag that creates the simlink. I'm gentooist : I'd rather do it manually, so that I know what happens in my box !

Thanks to all for all those comments.

[i92guboj]

Actually, that turns out not to be the case. Emerge will remove any unmodified file that it installed. That means that a --depclean will remove all of the kernel source but none of the work products. All of the build cruft (principally .o files) will be left but the kernel source will be gone. It is true that the installed kernel binaries (in /boot and /lib/modules) will not be touched.

- John

Yes. Portage will only erase the files it created itself. The products of kernel compilations were not created by portage, nor the files under /boot or /lib/modules (they were created by *you*, using genkernel, make fooo or whatever else). The .config files won't be touched either, which is a very good thing.

So, the users that like to try dozens of kernels every week should probably keep an eye on /lib/modules and the other on /boot, in case they grow too big.

[piedar]

What I particularly do is to add gentoo-sources to package.provided, then download the latest stable from kernel.org to my home directory, where I can build the kernel without being root (still don't know why would I need to be root just to compile a kernel...).

I use gentoo-sources, but I always chown /usr/src/linux to my user before compiling.

[The Doctor]

... where I can build the kernel without being root (still don't know why would I need to be root just to compile a kernel...).

wouldn't it be a serous security problem if a user could modify the kernel config/compile the kernel? It seems to me that a single user with hostile intent could add a patch or otherwise tamper with the kernel source much more easily than if the kernel source is owned by root.

[Hu]

What I particularly do is to add gentoo-sources to package.provided, then download the latest stable from kernel.org to my home directory, where I can build the kernel without being root (still don't know why would I need to be root just to compile a kernel...).

I use gentoo-sources, but I always chown /usr/src/linux to my user before compiling.

Why use chown? Write all build products to a user-owned area and leave the sources in the root-owned /usr/src/linux. This is fully supported via $KBUILD_OUTPUT and friends.

... where I can build the kernel without being root (still don't know why would I need to be root just to compile a kernel...).

wouldn't it be a serous security problem if a user could modify the kernel config/compile the kernel? It seems to me that a single user with hostile intent could add a patch or otherwise tamper with the kernel source much more easily than if the kernel source is owned by root.

Could you explain how being able to compile the kernel is a security problem, but being able to compile non-kernel packages by hand, e.g. glibc, is not a security problem? You still need root privilege to install the kernel into the location where the bootloader will use it. You still need root to install the kernel modules, if you built any. You can use a dedicated build user if you are concerned that other processes owned by your user might tamper with the kernel configuration.

[The Doctor]

Could you explain how being able to compile the kernel is a security problem, but being able to compile non-kernel packages by hand, e.g. glibc, is not a security problem? You still need root privilege to install the kernel into the location where the bootloader will use it. You still need root to install the kernel modules, if you built any. You can use a dedicated build user if you are concerned that other processes owned by your user might tamper with the kernel configuration.

I was thinking along the lines of modifying the source so that when it was installed it would be altered or setting up a tainted kernel if bzImage was symlinked to /boot. I suppose this was general if Gentoo was configured to allow user to modify and compile the kernel source wouldn't that be a security risk?

[Hello71]

Could you explain how being able to compile the kernel is a security problem, but being able to compile non-kernel packages by hand, e.g. glibc, is not a security problem? You still need root privilege to install the kernel into the location where the bootloader will use it. You still need root to install the kernel modules, if you built any. You can use a dedicated build user if you are concerned that other processes owned by your user might tamper with the kernel configuration.

I was thinking along the lines of modifying the source so that when it was installed it would be altered or setting up a tainted kernel if bzImage was symlinked to /boot. I suppose this was general if Gentoo was configured to allow user to modify and compile the kernel source wouldn't that be a security risk?

What? "Yes, it would be a bad idea to execute code of unknown origin as root."

[The Doctor]

...

....

What? "Yes, it would be a bad idea to execute code of unknown origin as root."

What I am talking about is if the kernel was designed so that root privileges were NOT required to work with it by default. Basically sidestepping the root user so to speak. My point was that if a file is owned by root it makes it harder to tamper with than a user's file.

[Hu]

I think you need to clarify what you mean by "work with it" [the kernel]. Do you mean "work with it" to be "compile and link the kernel" or do you mean it to be "install the kernel in a location that the bootloader will respect?" Like any other decent build system, the kernel is designed so that you can build it without root privilege. This is only a security problem if root installs a kernel built by a user who cannot be trusted to build a good kernel. If root installs kernels from an untrusted user, it does not matter whether that user built the kernel as himself using subverted sources or installed Linux on a separate computer, used his personal machine's root account to build a subverted kernel, and then copied it to the machine in question. For any trusted package, root must ensure that the files are from a trusted source. As much as possible, root must also ensure that, having received the files from a trusted source, no one except the local root user can modify them afterward.

You speak of a symlink to bzImage. Do you mean that you think root would create a symlink that points to a user-owned kernel image?

[The Doctor]

I think you need to clarify what you mean by "work with it" [the kernel]. Do you mean "work with it" to be "compile and link the kernel" or do you mean it to be "install the kernel in a location that the bootloader will respect?"

I meant compile and possibly leave in a place were the administrator might install it without realizing that it was unsafe or possibly exploit a symlink to install the kernel directly without gaining root privileges.

You speak of a symlink to bzImage. Do you mean that you think root would create a symlink that points to a user-owned kernel image?

I was thinking of a design where, for example, to have a user own /usr/src/linux or allowed users to read/write by default. In such a case wouldn't the a symlinked bzImage be respected even if the original was overwritten? I was simply thinking out loud about what it would mean to change the current system of having the folder owned by root to allow the kernel to be compiled by a user.

Perhaps I misread i92guboj post, but he seemed to imply that it would be a better design in root privileges were not required to compile the kernel by default. I was speculating that weakling the protection of the kernel source at any point seems to me to increase the risk that it might be compromised.

[i92guboj]

... where I can build the kernel without being root (still don't know why would I need to be root just to compile a kernel...).

wouldn't it be a serous security problem if a user could modify the kernel config/compile the kernel? It seems to me that a single user with hostile intent could add a patch or otherwise tamper with the kernel source much more easily than if the kernel source is owned by root.

No. You need to be root to install it, to install the modules, and to modify your bootloader. The user can compile as much as he likes on his/her home, but that will only give him the joy of seeing the compilation messages. The user can't run a kernel, or install it, without root permissions.

Of course, if you are root and you give your users kernels to compile, and then you install them without any attention then we have a problem. But if you are such kind of person, you will just probally give your random user root access so s/he can compile any random rootkit anyway.

The fact that you are toying with many millions files on a rw-mounted root fs as root seems much more dangerous to me, in addition to being unnecessary.

But to tell the truth, in Gentoo we do that all the time.