Bug 732046

Summary: SELinux is preventing /bin/systemd-tmpfiles from 'unlink' accesses on the file rng_update.lock.
Product: [Fedora] Fedora Reporter: Ricardo Alves Teixeira <rtmetz92>
Component: clusterAssignee: Fabio Massimo Di Nitto <fdinitto>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: agk, ccaulfie, cfeist, dominick.grift, dwalsh, extras-orphan, fdinitto, harald, johannbg, jpokorny, kay, lhh, lpoetter, mbroz, metherid, mgrepl, mschmidt, notting, plautrba, rmccabe, rtmetz92, swhiteho
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:bd94680269d700de4eb08b445575c618657019976865bc8aac41f8456dcd361f
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 16:14:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ricardo Alves Teixeira 2011-08-19 15:24:49 UTC
SELinux is preventing /bin/systemd-tmpfiles from 'unlink' accesses on the file rng_update.lock.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that systemd-tmpfiles should be allowed unlink access on the rng_update.lock file 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 systemd-tmpfile /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:systemd_tmpfiles_t:s0
Target Context                system_u:object_r:cluster_var_lib_t:s0
Target Objects                rng_update.lock [ file ]
Source                        systemd-tmpfile
Source Path                   /bin/systemd-tmpfiles
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           systemd-units-26-8.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-35.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.40-4.fc15.x86_64 #1 SMP
                              Fri Jul 29 18:46:53 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Fri 19 Aug 2011 04:13:57 PM WEST
Last Seen                     Fri 19 Aug 2011 04:13:57 PM WEST
Local ID                      3d9adb4a-48b9-4e02-b3a4-f1549c929841

Raw Audit Messages
type=AVC msg=audit(1313766837.775:85): avc:  denied  { unlink } for  pid=3565 comm="systemd-tmpfile" name="rng_update.lock" dev=dm-1 ino=2097218 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:cluster_var_lib_t:s0 tclass=file


type=SYSCALL msg=audit(1313766837.775:85): arch=x86_64 syscall=unlinkat success=yes exit=0 a0=7 a1=19b0bdb a2=0 a3=7fff4da88e71 items=0 ppid=1 pid=3565 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=/bin/systemd-tmpfiles subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null)

Hash: systemd-tmpfile,systemd_tmpfiles_t,cluster_var_lib_t,file,unlink

audit2allow

#============= systemd_tmpfiles_t ==============
allow systemd_tmpfiles_t cluster_var_lib_t:file unlink;

audit2allow -R

#============= systemd_tmpfiles_t ==============
allow systemd_tmpfiles_t cluster_var_lib_t:file unlink;

Comment 1 Daniel Walsh 2011-08-20 10:44:18 UTC
Did you move some cluster data to /tmp?

Do we setup systemd-tmpfiles to walk through /var/lib/cluster?

Comment 2 Ricardo Alves Teixeira 2011-08-20 14:34:16 UTC
(In reply to comment #1)
> Did you move some cluster data to /tmp?
> 
> Do we setup systemd-tmpfiles to walk through /var/lib/cluster?

I didn't move anything. I think this bug happened when I was updating the operating system via the Fedora 15 Software Update tool.

Comment 3 Lennart Poettering 2011-08-22 21:06:37 UTC
Hmm, which package is responsible for rng_update.lock and in which directory is this file placed in?

Comment 4 Jan Pokorný [poki] 2011-10-07 14:00:27 UTC
I found rng_update.lock being referred from one of the shell scripts in
cluster.git [1].  As I found similarly named scripts in RHEL 6 belonging
to cman (except for ccs_sync belonging to ricci), I then tried to install
cman in Fedora 16 and checked that in effect "ccs_update_schema" script was
also installed and it belongs to cman:

# rpm -qf $(which ccs_update_schema)
cman-3.1.7-1.fc16.x86_64

Thus, reassigning.

[1] http://git.fedorahosted.org/git/?p=cluster.git;a=blob;f=config/tools/xml/ccs_update_schema.in;h=d082ed36a04982206e9d3ec775bea3ab32498ddc;hb=e236677a5c238673a94923c34dcd4f83f4c9374b

Comment 6 Fabio Massimo Di Nitto 2011-10-07 14:10:20 UTC
(In reply to comment #1)
> Did you move some cluster data to /tmp?
> 
> Do we setup systemd-tmpfiles to walk through /var/lib/cluster?

ccs_update_schema (shipped from cluster srpm | cman rpm) does use /tmp and move stuff into /var/lib/cluster.

Comment 7 Fedora End Of Life 2012-08-07 16:14:22 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping