Bug 637900

Summary:	sys-apps/sysvinit - /etc/inittab should be protected by CONFIG_PROTECT by default
Product:	Gentoo Linux	Reporter:	lperkins
Component:	Current packages	Assignee:	Gentoo's Team for Core System packages <base-system>
Status:	UNCONFIRMED ---
Severity:	normal
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description lperkins 2017-11-16 22:59:07 UTC

/etc/inittab as installed by the sysvinit package is not subject to config protection.

If you reinstall sysvinit, congratulations, any customizations you've made are gone with no warning.

If you install/upgrade sysvinit from a binpackage made with quickpkg's default settings, congratulations, you just replaced your inittab with a one-line apology for not having included the actual config file, and your system is now unbootable.

Comment 1 lperkins 2017-12-27 20:01:24 UTC

I tried to reproduce this on another machine and failed, so I did a bit more digging.

I discovered the issue when attempting to use emerge with the --root parameter to repair a system which had ended up with the wrong cflags.  At this point I strongly suspect that the overwriting occurred before I had gotten the system fixed enough to chroot in and continue rebuilding things normally.

So, the question is how do --root and config-protect interact?  I know that, during the process, it was respecting config-protect on the rescue filesystem because I was having to approve the changes for installing the build-dependencies, but the config files being changed were the ones in /etc/portage of the rescue filesystem. 

I'm guessing that when one uses --root to install the packages somewhere else the normal config-protect settings get left behind.  If that is the case I would suggest that it should probably be changed to not do that since it ends up walking all over the configuration files with no backups.