Hide Forgot
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:
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.
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.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
This was fixed in OSP 10 release, Closing accordingly Sean