I just noticed that my test Fedora 29 amanda client has not been generating index files for some time. Instead of a proper index, the compressed index file on the server contains: //sbin/xfsrestore: ERROR: unable to create /xfsrestorehousekeepingdir.29047: Permission denied This has been happening since at least October. Oops. I do not know what changed but certainly this used to work. My best guess for a fix is to either: * Make sure to change directory to somewhere writable when spawning xfsrestore in the backup pipeline to extract the index. * Use the -a option to xfsrestore and provide a writable directory. It might be possible to accomplish the former simply by adding WorkingDirectory= to the systemd unit (amanda@.service). I'll try that tonight and see if it helps at all.
No luck just using WorkingDirectory=, sadly. Note that this isn't an selinux issue as I have amanda running in the permissive domian (though there are a few AVCs which I would look at if I had the time). One intersting thing I found is that in /var/log/amanda is an old xfsrestorehousekeepingdir.XXXX directory, dated in August. So it seems that it _used_ to write the directory there, but sometime between August and October, that stopped. Interestingly, the amanda-client package updated from 3.5.1-9 to 3.5.1-14 on September 20 and that update included some changes to /var/log/amanda directory permissions. So I have to wonder if that could be related somehow. I'll build a copy of the old package and see if it works better tonight.
I have verified that 3.5.1-9 does correctly generate the indices. So.... the only changes between that and -14 which aren't rebuilds: commit 994c3d9d055795c098c8de663301a5639fcaebb0 (origin/f29, origin/f28, origin/f27) Author: Vaclav Dolezal <vdolezal> Date: Mon Jul 30 15:13:06 2018 +0200 Modify permisions of /var/log/amanda/amandad directory commit 3ffd85638005b7370f239675d044765a347b416f Author: Josef Ridky <jridky> Date: Mon Apr 30 15:00:08 2018 +0200 Modify /var/log/amanda directory permission commit d81d0c97cd3c219d6ddeb594c251595920abc4a3 Author: Josef Ridky <jridky> Date: Thu Apr 12 09:12:41 2018 +0200 Remove perl(Dancer2) requirements I can't imagine it's the latter, and we've established that for some reason that xfs housekeeping directory is written to /var/log/amanda so it must be one of the other two. There's no explanation for those changes in the git log, but the RPM changelog mentions "selinux issues". I'm not sure what those were. Digging through the xfsrestore source with Eric Sandeen on IRC and it seems obvious that passing "-a /var/lib/amanda" is the proper fix. Keeping this thing in /var/log/amanda (which I believe is merely the CWD at the point where xfsrestore is done) has always been wrong anyway. But there's still no indication within the xfsrestore code of why a permission change like this would matter. I have a feeling there's some part of Amanda itself which changes because of the differing permissions, and the xfsrestore fallout is merely a side effect. Will patch in -a /var/lib/amanda and see what happens tonight.
Verfied that adding -a /var/lib/amanda to the xfsrestore command line during index generation fixes the problem.
amanda-3.5.1-16.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9dca788639
amanda-3.5.1-16.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9dca788639
amanda-3.5.1-16.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
Hello, analysis of the root cause of the problem was provided in bz2000179. Indeed, "Modify /var/log/amanda directory permission" was the culprit. The permissions got modified because SELinux did not like kamandad (kerberized amandad, which runs with root permissions) accessing /var/log/amanda if the latter is not owned by root but by the amanda user (amandabackup) and not group-accessible: ---- type=PROCTITLE msg=audit(04/27/2018 11:01:21.898:365) : proctitle=/usr/sbin/amandad -auth=krb5 amdump amindexd amidxtaped type=PATH msg=audit(04/27/2018 11:01:21.898:365) : item=0 name=/var/log/amanda/amandad/ inode=262526 dev=fd:01 mode=dir,700 ouid=amandabackup ogid=disk rdev=00:00 obj=system_u:object_r:amanda_log_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(04/27/2018 11:01:21.898:365) : cwd=/var/log/amanda type=SYSCALL msg=audit(04/27/2018 11:01:21.898:365) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffffffffffff9c a1=0x559e292b3d20 a2=O_WRONLY|O_CREAT|O_EXCL|O_APPEND a3=0x1a0 items=1 ppid=1 pid=29597 auid=unset uid=root gid=disk euid=root suid=root fsuid=root egid=disk sgid=disk fsgid=disk tty=(none) ses=unset comm=amandad exe=/usr/lib64/amanda/amandad subj=system_u:system_r:amanda_t:s0 key=(null) type=AVC msg=audit(04/27/2018 11:01:21.898:365) : avc: denied { dac_override } for pid=29597 comm=amandad capability=dac_override scontext=system_u:system_r:amanda_t:s0 tcontext=system_u:system_r:amanda_t:s0 tclass=capability permissive=0 ----