Hide Forgot
Description of problem: 1. run amrecover to restore from amanda backup 2. select files to restore 3. extract files SELinux is preventing /usr/lib64/amanda/amindexd from 'remove_name' accesses on the directory 20130817010503_0. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that amindexd should be allowed remove_name access on the 20130817010503_0 directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep amindexd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:amanda_t:s0 Target Context unconfined_u:object_r:admin_home_t:s0 Target Objects 20130817010503_0 [ dir ] Source amindexd Source Path /usr/lib64/amanda/amindexd Port <Unknown> Host (removed) Source RPM Packages amanda-server-3.3.3-4.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-74.3.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.10.11-200.fc19.x86_64 #1 SMP Mon Sep 9 13:03:01 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-09-15 16:59:34 CDT Last Seen 2013-09-15 16:59:34 CDT Local ID 4873f387-cdcb-4919-9085-51bd242d73e4 Raw Audit Messages type=AVC msg=audit(1379282374.785:4041): avc: denied { remove_name } for pid=25477 comm="amindexd" name="20130817010503_0" dev="dm-0" ino=3810633 scontext=system_u:system_r:amanda_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=dir type=AVC msg=audit(1379282374.785:4041): avc: denied { unlink } for pid=25477 comm="amindexd" name="20130817010503_0" dev="dm-0" ino=3810633 scontext=system_u:system_r:amanda_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=file type=SYSCALL msg=audit(1379282374.785:4041): arch=x86_64 syscall=unlink success=yes exit=0 a0=7fd6e5697310 a1=7fd6e5655e80 a2=0 a3=7fff227ca060 items=0 ppid=25476 pid=25477 auid=4294967295 uid=33 gid=6 euid=33 suid=33 fsuid=33 egid=6 sgid=6 fsgid=6 ses=4294967295 tty=(none) comm=amindexd exe=/usr/lib64/amanda/amindexd subj=system_u:system_r:amanda_t:s0 key=(null) Hash: amindexd,amanda_t,admin_home_t,dir,remove_name Additional info: reporter: libreport-2.1.7 hashmarkername: setroubleshoot kernel: 3.10.11-200.fc19.x86_64 type: libreport
Why is it creating 20130817010503_0 in the /root?
(In reply to Daniel Walsh from comment #1) > Why is it creating 20130817010503_0 in the /root? amrecover can only be run as root. I don't know why that temp directory was created in /root. amrecover was started by the root user from /root/temp.
Ok so it probably creates the directory under the current directory that you are in. If you ran in enforcing mode I would figure the directory is in /root/temp. If you ran amrecover in /var/tmp, I would bet it works.
I tried running amrecover from the /var/tmp/recover directory. I got the same result as before. The directory it is referring to is located in /var/lib/amanda/DailySet1/index/cid.localdomain/_home Running in permissive mode generated 86 other selinux errors regarding /usr/bin/perl and /usr/bin/ps
Please attach the new AVC's
After running "restorecon -v -r /var/lib/amanda/" (there were many corrections), I ran amrecover again from the /var/tmp/recover directory with selinux set to permissive mode. This reduced the number of selinux errors to 6. See attachments.
Created attachment 799518 [details] selinux detail 1
Created attachment 799519 [details] selinux detail 2
Created attachment 799521 [details] selinux detail 3
Created attachment 799522 [details] selinux detail 4
Created attachment 799523 [details] selinux detail 5
Created attachment 799524 [details] selinux detail 6
A lot easier to respond to these as separate bugs. But Why is amidxtaped dealing with fusefs files? Why is it trying to write to the changer file in /etc/amanda? I updated policy 198cf8f077edb8522749a33f383da7df5ba0da36 to allow amanda to read /dev/urand.
The 6 AVC's were attached to this bug report as you requested in Comment 5. Please feel free to bust them up into separate bugs. I have no idea why amidxtaped is accessing fusefs files. The /etc/amanda/DailySet1/changer file appears to be written to when a backup is made by amanda as the amandabackup user. I do not know why the root user tries to write to this file when amrecover is run.
Ok adding label for DailySet /etc/amanda/DailySet1(/.*)? gen_context(system_u:object_r:amanda_data_t,s0) You can test this with chcon -R -t amanda_data_t /etc/amanda/DailySet1
selinux-policy-3.12.1-74.9.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-74.9.fc19
Package selinux-policy-3.12.1-74.9.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-74.9.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18701/selinux-policy-3.12.1-74.9.fc19 then log in and leave karma (feedback).
selinux-policy-3.12.1-74.9.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.