Hello, the permissions were changed due to bz1572696 (the original permissions caused SElinux denials when starting kamanda). By the way, is there a customer case for the problem?

If there's a customer case, I'm not aware of it.  The problem was observed on a derived distribution (AlmaLinux 8), not directly on a Red Hat Enterprise Linux system.  However, note that Red Hat customers are not likely to become aware of the problem until they need to try to recover a file from their Amanda backups and discover that amrecover cannot retrieve them, so it is very much in Red Hat's interest to be proactive about this issue.

I don't have access to bz1572696.  By "kamanda", do you just mean Amanda configured to use a daemon running at port 10081 (i.e., with "amandad -auth=krb5)?

Is it possible that the reason widening the permissions on /var/log/amanda fixed the SElinux problems with kamanda was not because group permissions on the directory are actually required, but that, as a side effect, it caused amandad to refuse to use /var/log/amanda as a safe working directory (and thus SElinux denying access to that location was no longer relevant)?  

As far as you are aware, would removing group permissions from /var/log/amanda be a practical workaround if a site is not using Kerberos, and/or if SELinux is disabled?  Or would this result in other known problems?

(In reply to Dan Astoorian from comment #2)
> However, note that Red Hat customers are not
> likely to become aware of the problem until they need to try to recover a
> file from their Amanda backups and discover that amrecover cannot retrieve
> them, so it is very much in Red Hat's interest to be proactive about this
> issue.

I see, thanks for pointing out this and for the report! Yeah, bugs that show up at restore time and not at backup time are nasty. One really needs to test backups before using them. At least I am glad that the data are actually there.

Concerning bz1299761, sorry, it is private, I'll try to summarize what I understood: yes, kamanda is amanda configured to use Kerberos authentication. There is a service file for this usage: kamanda@.service. If you look inside, you will see that it runs amandad as root, not as the usual user (not sure why off the top of my head, presumably to access a keytab?) which is apparently the root of the problem - selinux does not like root accessing this directory using its "appropriate privileges". Yes, I think removing group permissions would be an acceptable workaround if you don't use kamanda nor SELinux in enforcing mode.

Thanks for the clarification.

Hopefully the permissions can be restored to what Amanda's safe_cd() is expecting by fixing the SElinux policy to allow amandad to access what it needs when run as root (since changing amandad's working directory from /var/log/amanda to / as a side effect of the permission change may have other unforeseen consequences).

Is it known why this was not an issue on Red Hat Enterprise 7 and earlier?

(In reply to Pavel Cahyna from comment #4)

> it runs amandad as root, not as the usual user (not sure why off the top 
> of my head, presumably to access a keytab?)

indeed, that's the case - see amanda-auth(7): "Note that you're running this as root, rather than as your dump user. AMANDA will set its UID down to the dump user at times it doesn't need to read the keytab file, and give up root permissions entirely before it goes off and runs dump. Alternately you can change your keytab files to be readable by user amanda. You should understand the security implications of this before changing the permissions on the keytab."

Support for kerberized Amanda was added in Fedora in bz1077642 and RHEL then inherited it.

It looks like the permissions on /var/log/amanda were changed sometime between amanda-3.5.1-9.fc28.x86_64.rpm and amanda-3.5.1-14.fc29.x86_64.rpm, so Fedora 29 may have had the same deficiency.

Fedora 30 included a patch ("patch-xfsrestore-housekeeping") which avoided the problem by specifying "-a /var/lib/amanda" as parameters to the xfsrestore command, but this fix apparently has not made its way into Red Hat Enterprise Linux 8.  It may not be as clean a fix as making /var/log/amanda "safe" for the purposes of safe_cd(), but it would fix the problem at hand.

Thanks a lot for the analysis and finding the solution! The Fedora bugreport is bz1671117.

I've built packages with the same change as in Fedora, available at https://people.redhat.com/pcahyna/amanda/. Please test.

Unfortunately, I don't currently have any systems appropriate for testing; I have only production systems available (running AlmaLinux 8, a derived distribution), which are using the workaround above, i.e., removing group permissions from /var/log/amanda.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.