Bug 141512

Summary: /etc/issue{,.net} are replaced on installation of fedora-release package
Product: [Fedora] Fedora Reporter: Aaron Gaudio <madcap>
Component: fedora-releaseAssignee: Elliot Lee <sopwith>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-01 21:11:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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).