Red Hat Bugzilla – Bug 11247
RPM and upgrade errors
Last modified: 2008-05-01 11:37:55 EDT
I applied the 6.2 upgrade to a 6.0 system not realizing that the system had
chattr +i -R'd /lib,/bin,/sbin,/usr, /etc/rc.d, /etc/mail and other misc
files. The install script continued along its happy way NOT installing
some files nor generating any error messages. When the machine was
rebooted, it was all messed up because it had somehow managed to delete
/etc/inittab and did not replace it with something useful. It did manage
to update the package database so a subsequent upgrade thought everything
was up to date and didn't want to install the new software.
Um, rpm is totally unprepared to deal with chattr (or even rdonly) file systems.
Until chattr is more widely (and consistently) used, I see little need to teach
rpm about chattr. For now, just "Don't do that!".
I feel that this is unfortunate. I have been teaching a LOT of people to use
the immutable bit on critical files and directories and it has saved a number of
systems from being broken into in the past (sometimes by crackers, sometimes by
a manager who gained access to a console logged in as root).
I guess I really feel that it isn't reasonable for RPM to continue doing its
thing without telling anyone of any errors or warnings and later going 'doh
because it failed or partially failed (totally failing seems easier to deal with
than partially failing). Believe me, after doing this once, the second time you
do it to yourself, you sort of feel like the Coyote (oh no!).
The feature request for rpm is not discarded, only deferred. Before chattr,
the rdonly file system problems need to be resolved, and before that a
less naive scheme than the current netsharedpath mechanism needs to be
FWIW, part of teaching people to use chattr involves explaining how
the use of chattr affects other programs like rpm, etc ...
This is significantly more serious than the current bug report gives credit.
We recently found a machine with chattr +i on /bin/login and a few other files.
In particular this meant that when upgraded it silently failed up upgrade these
packages, although there was a note on one of the virtual consoles.
This was in relation to a hacking incident - it meant that if the machine
that had been hacked had been upgraded then the back door that the hacker
placed there would have survived. This _has_ to be an issue, since
traditionally an upgrade would be considered a safe way of removing problems
with a compromised machine.
If nothing else the installation should come up with big red flags complaining
that it cannot upgrade a package.
Collecting RO problems at #52190.
*** This bug has been marked as a duplicate of 52190 ***