Bug 1121290 - /etc/amanda/.*/changer needs to be amanda_data_t
Summary: /etc/amanda/.*/changer needs to be amanda_data_t
Alias: None
Product: Fedora
Classification: Fedora
Component: amanda
Version: 24
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Josef Ridky
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-18 22:06 UTC by Orion Poplawski
Modified: 2016-08-23 12:39 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-08-23 12:39:11 UTC

Attachments (Terms of Use)
Patch for movement /etc/amanda/.. to /var/lib/amanda (4.09 KB, patch)
2014-10-29 12:41 UTC, Petr Hracek
no flags Details | Diff

Description Orion Poplawski 2014-07-18 22:06:15 UTC
Description of problem:

I'm running a custom amanda 3.3.6 on EL6 and get:

type=AVC msg=audit(1405719159.849:257884): avc:  denied  { write } for  pid=8744 comm="amidxtaped" name="changer" dev=dm-0 ino=16008 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:amanda_config_t:s0 tclass=file

trying to run amrecover.

I'm using a fairly standard "tpchanger chg-disk:" configuration, and I'm not specifying the location of this "/etc/amanda/Data/changer" file, so I think it's pretty standard amanda.

It would be nice to get this into all released versions EL6+, though I think this is new sometime between amanda 3.3.1 and 3.3.6.

Comment 1 Miroslav Grepl 2014-07-21 09:57:38 UTC
What does

# rpm -qf /etc/amanda/Data

Comment 2 Orion Poplawski 2014-07-21 18:45:44 UTC
file /etc/amanda/Data is not owned by any package

When using Amanda, you create arbitrary configurations in /etc/amanda/<configname>.  It ships with a default /etc/amanda/DailySet1, but generally users will create their own configs, hence:

/etc/amanda/.*/index(/.*)?   system_u:object_r:amanda_data_t:s0
/etc/amanda/.*/tapelist(/.*)?        system_u:object_r:amanda_data_t:s0

Comment 3 Miroslav Grepl 2014-08-01 10:56:50 UTC
Why does amanda write own config files?

Comment 4 Jason Tibbitts 2014-08-08 19:30:32 UTC
That's just how it works.  I can't say that it's remotely intelligent, but amanda stores several things under /etc/amanda that should really be in /var/lib/amanda. Things I've seen amanda write under /etc/amanda/CONF:


I'm sure there are more.  It is almost certainly possible to patch these, but I suppose someone should instead pressure upstream to allow specifying a separate path for these writable "configuration files".

Comment 5 Miroslav Grepl 2014-09-01 10:59:53 UTC
So is there a change to move it?

Comment 6 Petr Hracek 2014-09-05 10:43:37 UTC

on the base of configure script directive --with-configdir could be used for this issues. But I have to clarify whether it is used for our case.

Comment 7 Petr Hracek 2014-09-05 11:44:25 UTC

response from upstream is that directive can be used for this issue.

I will test that soon.

Comment 8 Petr Hracek 2014-10-29 12:41:19 UTC
Created attachment 951765 [details]
Patch for movement /etc/amanda/.. to /var/lib/amanda

This is the patch which should solved the issues.

It would be good to test especially %post section

Comment 9 Petr Hracek 2014-11-12 08:27:48 UTC
Question for this is that if we change the location for amanda configurations to /usr/lib/amanda/... then /etc/amanda won't be used for backups anymore.

Do you think that this is a correct propose?
If admin uses /etc/amanda directory then this directory will not be used by amanda software.

Comment 10 Petr Hracek 2014-12-02 13:31:10 UTC
What do you think about my proposal?
See my comments above?

Comment 11 Orion Poplawski 2014-12-02 15:39:20 UTC
No, I don't think this is the way to go.  Configuration still belongs in /etc/amanda.  The problem is that amanda puts some state information into configdir - specifically the tapelist* and changer files.  This is going to need to be addressed upstream.

Comment 12 Orion Poplawski 2014-12-02 17:00:16 UTC
Looks like the easy solution is:

changerfile "/var/lib/amanda/DailySet1/changer"

Comment 13 Orion Poplawski 2014-12-02 17:01:21 UTC
Probably should set tapelist while we're at it too.

Comment 14 Jean-Louis Martineau 2014-12-02 17:17:18 UTC
Changing the default location will break every configuration that upgrade.

If the default location is changed, code that verify and FAIL if the files are not in the right location must be added.

PS. The tapelist and all others paths can be set in the configuration file.

Also check the indexdir, logdir and infofile.

Comment 15 Jason Tibbitts 2014-12-02 18:51:08 UTC
It is perfectly acceptable to change the default location in between Fedora releases; breakage is permitted there though a release note would be pretty important.  It is not necessary to try and do automatic conversion, and certainly never appropriate to fail an upgrade in that way (because you can't actually fail an upgrade; scriptlet failure at best does nothing and at worst just screws up the system state).

If these are specified in the configuration file, you can certainly change the default any time you like because configuration files aren't overwritten on package upgrades (assuming they're marked %config(noreplace) as amanda.conf is.

Comment 16 Jaroslav Reznik 2015-03-03 16:08:16 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:

Comment 17 Jan Kurik 2016-02-24 15:48:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:

Comment 18 Fedora Admin XMLRPC Client 2016-07-11 10:13:39 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 19 Josef Ridky 2016-08-23 12:39:11 UTC
Closing as WONTFIX, the solution from #c12 should be sufficient.

Feel free to reopen this bug, if you think, that provided solution is not sufficient.

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