Bug 1334045

Summary:	Configuration files are reset on upgrade
Product:	Red Hat Enterprise Linux 7	Reporter:	Peter Bex <airhead>
Component:	ImageMagick	Assignee:	Jan Horak <jhorak>
Status:	CLOSED CANTFIX	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.4
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-05-09 07:39:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Peter Bex 2016-05-07 13:45:56 UTC

Description of problem:

Upon upgrading (or reinstalling) the ImageMagick package, my changes to /etc/ImageMagick/policy.xml got lost.

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

ImageMagick.x86_64 6.7.8.9-12.el7_2

How reproducible:

Steps to Reproduce:
- Tweak /etc/ImageMagick/policy.xml
- yum reinstall ImageMagick

Actual results:

policy.xml retains the changes made by the user.

Expected results:

policy.xml got reset to the original version from the package.

Additional info:

This is quite dangerous, considering a change to policy.xml is the suggested workaround for [bug 1332505]. I'm using the ImageMagick-last package from Remi Collet, which is based on the stock RHEL package, so there was an upgrade.  The upgrade _also_ threw away my changes.

Comment 1 Peter Bex 2016-05-07 13:51:31 UTC

A workaround for this bug is to mark the file immutable, using chattr +i /etc/ImageMagick/policy.xml but this is a bit of a hack.

Luckily, yum will warn when it is unable to remove the file, but still continues.

Comment 3 Peter Bex 2016-05-07 14:45:29 UTC

Correction: In my bugreport, "actual results" and "expected results" should be swapped. Sorry for any confusion this might have caused!

Comment 4 Jan Horak 2016-05-09 07:39:55 UTC

I'm afraid that we're preferring security over user configuration. Currently there's no other way to prevent published attacks. We're sorry about your inconveniences.

Comment 5 Peter Bex 2016-05-09 07:51:31 UTC

I was trying to secure my config by adding the policy restrictions (the default one had no restrictions at all), but a reinstall or upgrade removed these, making me _less_ secure. I don't understand how that is "preferring security over user configuration": the net effect to me was that I got neither user configuration *nor* security.