Bug 1307186

Summary: Swift selinux denial on trying to write to /var/log/ceilometer
Product: Red Hat OpenStack Reporter: David Hill <dhill>
Component: rhosp-directorAssignee: Christian Schwede (cschwede) <cschwede>
Status: CLOSED CURRENTRELEASE QA Contact: Shai Revivo <srevivo>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: dbecker, derekh, dtantsur, jcoufal, kbasil, mabrams, mburns, morazi, pgrist, rhel-osp-director-maint, scohen, sgotliv, srevivo, thiago, zaitcev
Target Milestone: ---   
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-23 14:45:32 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:

Description David Hill 2016-02-12 23:49:13 UTC
Description of problem:
For some reasons, swift-proxy wants to write in /var/log/ceilometer and is denied as per selinux policies:

type=AVC msg=audit(1455320564.879:742): avc:  denied  { write } for  pid=6346 comm="swift-proxy-ser" name="ceilometer" dev="dm-0" ino=102806390 scontext=system_u:system_r:swift_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
type=AVC msg=audit(1455320636.930:802): avc:  denied  { write } for  pid=6634 comm="swift-proxy-ser" name="ceilometer" dev="dm-0" ino=102806390 scontext=system_u:system_r:swift_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
type=AVC msg=audit(1455320636.930:802): avc:  denied  { add_name } for  pid=6634 comm="swift-proxy-ser" name="swift-proxy-server.log" scontext=system_u:system_r:swift_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
type=AVC msg=audit(1455320636.930:802): avc:  denied  { create } for  pid=6634 comm="swift-proxy-ser" name="swift-proxy-server.log" scontext=system_u:system_r:swift_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file


Version-Release number of selected component (if applicable):
Latest

How reproducible:
Always

Steps to Reproduce:
1. rm -rf /var/log/swift/* /var/log/ceilometer/*
2.
3.

Actual results:
swift-proxy fails to start

Expected results:
swift-proxy starts

Additional info:

Comment 2 Pete Zaitcev 2016-02-14 04:00:57 UTC
It's past time we found a solution to this. I have something like 5 bugs
open about it.

At this point I'm thinking about writing a whole new ceilometer middleware
that's not writing into files outside of the context in which it's running.
Just use some kind of blessed socket or whatever.

Comment 4 Pete Zaitcev 2016-02-15 20:10:17 UTC
I discussed this over with some stakeholders and here's what we have.

The problem is that a piece of middleware, provided by Ceilometer,
operates in the context of Swift as a plug-in, but updates event logs
that are owned by Ceilometer. It is by design. To make this work in
a typical POSIX environment, one creates a group, such as "ceiloswift"
and makes the right directories with 02000 flag and log files owned
by group "ceiloswift" (the name is an example). The user "ceilometer"
continues to own those directories and files as today. Then, user "swift"
is added to the gorup "ceiloswfit". Thus when Swift runs, it is able
to update the event logs.

Frankly I think this design is fragile and incurs sysadmin overhead
that automated installation may not be able to spare. But it is the
upstream.

Fixing this in the packaging requires manipulating groups with
groupmod(8), then setting the right groups to shared ownership
directories. It's a little scary and I don't know of a correct
precedent. It's easier for me to consider desperate measures in
comment #2.

So, for now, without removing the resposibility, I'm going to re-assign
this bug to OSP Director, and ask them (likely Giulio) to consider
if this can be baked into Puppet modules that have a combined view
of Ceilometer and Swift. They can easily fix-up groups and directory
bits in a consistent way (or so I hope). Feel free to get back with
this if it's asking for too much.

Comment 5 Mike Burns 2016-04-07 21:11:06 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 14 Sean Cohen 2016-11-23 14:45:32 UTC
This was fixed in OSP 10 release,
Closing accordingly
Sean