Hide Forgot
Version-Release number of selected component (if applicable): selinux-policy-3.12.1-86.el7.noarch RHEL-7.0-20131009.0 Actual results: time->Thu Oct 10 17:06:17 2013 type=PATH msg=audit(1381439177.060:89): item=1 name="certs" inode=67697954 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:slapd_cert_t:s0 objtype=DELETE type=PATH msg=audit(1381439177.060:89): item=0 name="/" inode=1396847 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT type=CWD msg=audit(1381439177.060:89): cwd="/" type=SYSCALL msg=audit(1381439177.060:89): arch=80000015 syscall=292 success=no exit=-13 a0=8 a1=10000cb92f3 a2=200 a3=3f252380 items=2 ppid=1 pid=17453 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-tmpfile" exe="/usr/bin/systemd-tmpfiles" subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null) type=AVC msg=audit(1381439177.060:89): avc: denied { rmdir } for pid=17453 comm="systemd-tmpfile" name="certs" dev="dm-1" ino=67697954 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:slapd_cert_t:s0 tclass=dir
Where is "certs" directory located in your case?
I am not sure, this AVC appeared only once. Here is a log where it appeared https://beaker.engineering.redhat.com/recipes/1080540#task16297972 . Peter, are you able to answer the question above as you are the test author? The other possibility is that it caused some earlier task in the job.
The AVC is reproducible on ppc64 with RHEL-7.0-20131011.n.0 build: ---- time->Fri Oct 18 04:59:01 2013 type=PATH msg=audit(1382086741.181:61): item=1 name="certs" inode=137312409 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:slapd_cert_t:s0 objtype=DELETE type=PATH msg=audit(1382086741.181:61): item=0 name="/" inode=68400318 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT type=CWD msg=audit(1382086741.181:61): cwd="/" type=SYSCALL msg=audit(1382086741.181:61): arch=80000015 syscall=292 success=no exit=-13 a0=8 a1=10039a692f3 a2=200 a3=34d62380 items=2 ppid=1 pid=16476 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-tmpfile" exe="/usr/bin/systemd-tmpfiles" subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null) type=AVC msg=audit(1382086741.181:61): avc: denied { rmdir } for pid=16476 comm="systemd-tmpfile" name="certs" dev="dm-1" ino=137312409 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:slapd_cert_t:s0 tclass=dir ---- Unfortunately, it is a beaker/TC issue: # find /var/tmp/ -inum 137312409 /var/tmp/beakerlib-16546152/backup/etc/openldap/certs # ls -dZ /var/tmp/beakerlib-16546152/backup/etc/openldap/certs drwxr-xr-x. root root system_u:object_r:slapd_cert_t:s0 /var/tmp/beakerlib-16546152/backup/etc/openldap/certs # What I don't know is, why was systemd-tmpfiles running in the same time and why it wanted to remove that directory? Was it on purpose or just a coincidence? If systemd-tmpfiles was lucky (there was a SELinux allow rule present) then the TC wouldn't be able to restore /etc/openldap/certs from backup, because the backup would have been deleted by systemd-tmpfiles.
systemd-tmpfiles seems to be to intrusive. Here is an idea for workaround: disable systemd-tmpfiles for a period when our TCs are running.
Ok, this is because of /var/tmp/beakerlib-16546152/backup location. I believe it should be fixed in tests.