Red Hat Bugzilla – Bug 64671
RFE: Catch errors when anaconda tries to modify immutable files
Last modified: 2007-03-26 23:53:13 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux)
Description of problem:
On a system with the lilo.conf file made immutable for security, installer failed to create the file.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Current lilo.conf file has chattr +i assigned.
2. Run installation from media.
3. Installer fails after determining it could not create new lilo.conf.
Actual Results: The system would boot with a recovery disk created during 7.3 installation. System would run on previous kernel allowing changes
to be made to the lilo.conf file. Manual editing of file completed
the media installation.
Expected Results: Anaconda could have alerted the system there was a problem with the file attribute so the lilo.conf file could be created correctly.
Attached anaconadump.txt with output.
Created attachment 56804 [details]
Dump file copied during installation.
Ed filed this at my request and suggestion.
For security reasons, they make certain files immutable in the business environment he is in -- this should have generated an error code, which
should have been passed up to anaconda for resolution
Additionally, perhaps, and with grub as well, this error, about a non-changeable conf file, should be trapped, and an exception raised.
The immutable bit affects installation of normal packages also. We put +i on a
handful of important system files as a security measure, and our web server
gave an error when upgrading 7.2 -> 7.3 (see message copied below) on
the "setup" package which includes the /etc/services file, which we had +i.
"There was an error installing ???. This can indicate media failure, lack of
disk space, and/or hardware problems. This is a fatal error and your install
will be aborted. Please verify your media and try your install again. Press the
OK button to reboot your system."
It would be very nice if this attribute could be detected. Even if the
installer didn't want to help you remove the bit, at least giving you an
opportunity to switch to the shell and do it would be convenient.
Perhaps a solution involves generalizing this back to rpm and making it detect
immutability on target files before starting an upgrade, and giving a pretty
error. If it did this as part of the rpm transaction preparation, anaconda
could prompt the user with a retry/cancel message (as in retry the rpm
transaction or cancel the upgrade) before it starts doing anything.
I second this request. EPERM in anaconda should diagnose all
protection bits, including immutable. rpm should check immutable
during the "preparing transaction" stage.
The priority of this request should be raised to at least Normal.
(It happened to me with /bin/cp having +i. It caused a _lot_
of head scratching.)
I have not seen another request for this since this bug was filed. I do not see
us including this functionality.