Bug 64671 - RFE: Catch errors when anaconda tries to modify immutable files
Summary: RFE: Catch errors when anaconda tries to modify immutable files
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-09 12:27 UTC by Ed Helwig
Modified: 2007-03-27 03:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-07 22:03:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Dump file copied during installation. (120.27 KB, text/plain)
2002-05-09 12:28 UTC, Ed Helwig
no flags Details

Description Ed Helwig 2002-05-09 12:27:26 UTC
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:

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.

Comment 1 Ed Helwig 2002-05-09 12:28:50 UTC
Created attachment 56804 [details]
Dump file copied during installation.

Comment 2 R P Herrold 2002-05-09 13:23:14 UTC
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.

Comment 3 Martin Flack 2002-05-21 00:13:51 UTC
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.

Comment 4 John Reiser 2002-06-11 15:24:47 UTC
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.)

Comment 5 Michael Fulbright 2003-03-07 22:03:42 UTC
I have not seen another request for this since this bug was filed.  I do not see
us including this functionality.

Note You need to log in before you can comment on or make changes to this bug.