Bug 1018722
Summary: | selinux prevents systemd-tmpfiles from removing directory labeled slapd_cert_t | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Dalibor Pospíšil <dapospis> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | dapospis, mmalik, psplicha |
Target Milestone: | beta | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-10-21 16:07:14 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dalibor Pospíšil
2013-10-14 09:37:04 UTC
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. |