Bug 141512 - /etc/issue{,.net} are replaced on installation of fedora-release package
Summary: /etc/issue{,.net} are replaced on installation of fedora-release package
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elliot Lee
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-01 18:54 UTC by Aaron Gaudio
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-12-01 21:11:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Aaron Gaudio 2004-12-01 18:54:19 UTC
Description of problem:
fedora-release package always overwrites /etc/issue, /etc/issue.net files.

Version-Release number of selected component (if applicable):
8

How reproducible:
Always

Steps to Reproduce:
1. Edit and customize your /etc/issue and/or /etc/issue.net files.
2. [Re-]Install the fedora-release package.
  
Actual results:
The custom /etc/issue is copied to /etc/issue.rpmsave and replaced
with the "standard" /etc/issue.

Expected results:
Custom edits of /etc/issue{,.net} should be preferred over the
"standard" ones. Especially considering that /etc/issue.net contains
OS name and version and may be viewable to network clients who can use
that information in an attack. Nevertheless, I am in a corporate
environment where we have a 'unauthorized access forbidden' login
prompt and there's no reason for the standard /etc/issue to overwrite
that every time I upgrade.

Applications shouldn't depend on the contents of /etc/issue to
determine OS version anyway; that's what /etc/fedora-release (or
better, /usr/bin/lsb_release) is for.

Additional info:

Comment 1 Elliot Lee 2004-12-01 21:11:11 UTC
This is a policy decision with some tradeoffs that clearly causes
problems in your situation. However, the overwriting is needed to make
/etc/issue updates happen properly in certain other situations, so
I'll probably stick with the current policy to upset the least number
of people.

Comment 2 Aaron Gaudio 2004-12-01 21:32:06 UTC
I don't understand what the other situations are... if you use the
confignoreplace option in the rpm spec (or whatever that option is),
it will overwrite the existing /etc/issue if it hasn't been edited;
otherwise it will create an /etc/issue.rpmnew and leave a
custom-edited /etc/issue alone. I can't see any situation in which
someone who has a custom-edited /etc/issue would need to have it
always replaced with the standard /etc/issue (and in the few cases in
which someone might want to do this, that's why the rpmnew file would
be there). 


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