Bug 1307186 - Swift selinux denial on trying to write to /var/log/ceilometer [NEEDINFO]
Swift selinux denial on trying to write to /var/log/ceilometer
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity urgent
: ---
: 10.0 (Newton)
Assigned To: Christian Schwede (cschwede)
Shai Revivo
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-12 18:49 EST by David Hill
Modified: 2016-11-23 09:45 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-23 09:45:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
scohen: needinfo? (mabrams)


Attachments (Terms of Use)

  None (edit)
Description David Hill 2016-02-12 18:49:13 EST
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-13 23:00:57 EST
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 15:10:17 EST
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 17:11:06 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 14 Sean Cohen 2016-11-23 09:45:32 EST
This was fixed in OSP 10 release,
Closing accordingly
Sean

Note You need to log in before you can comment on or make changes to this bug.