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): How reproducible: Always 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. Additional info: 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.