rabbitmqctl's use of su is blocked by SELinux on RHEL/CentOS 7 in the context of logrotate #32
Comments
|
The issue in Red Hat's Bugzilla is reported for RabbitMQ 3.3.5, which is close to 3 years old. If there is a way to reproduce this with a modern version, please post some details to rabbitmq-users, our public mailing list. |
|
Also, our team started producing CentOS 7 releases in the 3.6.x series. 3 years ago there was no CentOS 7 RPM produced by this team, so chances are the package in question is custom-built. |
|
The wrapper script is still the same in the master branch as is the replacement for SU_RABBITMQ_SH_C in the specfile to 'su rabbitmq -s /bin/sh -c'. Thus that's the same in the master and doesn't have anything to do with the old version in EPEL7. One difference I have just noticed is the missing postrotate section in the logrotate configuration. How does the server know when to reopen the log file? |
|
@gvde current releases are produced from the The server would create a log file when it does not exist. It would be very helpful if you could explain why the use of |
|
The problem seems to be that SeLinux on CentOS 7 doesn't allow to use su in the context of a logrotate script. I can't tell whether that is intentionally but it can't be worked around with a simple SeLinux policy either. Using sudo instead of su works fine for me. |
michaelklishin
changed the title
|
@gvde thanks for the details. Moved to rabbitmq/rabbitmq-server#1292 as currently the thinking is that we cannot work around this with packaging. |
|
rabbitmq/rabbitmq-server#1292 was closed with wontfixed. Thus it comes back here. If sudo isn't an alternative it's necessary to fix the selinux policies to be installed with the rhel7/centos7 rpms... |
|
@gvde we'd definitely welcome a PR with some ideas as to what the policies should be. Not sure how common it is for packages to install their own policies, by the way. |
|
I am also running into a similar issue on Centos 7 with RabbitMQ installed from the official repo (http://www.rabbitmq.com/releases/rabbitmq-server), installed version is 3.6.10. Logrotate fails with the following message: Digging through audit.log I found a denied access to /var/lib/rabbitmq/.erlang.cookie. audit2allow suggests the following two selinux rules to be added in order for logrotate for rabbitmq to work: root@n2 / # grep rabbitmq /var/log/audit/audit.log.1 | audit2allow
#============= logrotate_t ==============
allow logrotate_t rabbitmq_var_lib_t:dir { read write };
allow logrotate_t rabbitmq_var_lib_t:file getattr;Should the rabbitmq rpm ship with an updated SELinux policy or is this up to the user to update the policy? |
|
I'm leaning towards packages setting up policies like that.
…On Sun, Aug 13, 2017 at 10:50 AM, mliker ***@***.***> wrote:
I am also running into a similar issue on Centos 7 with RabbitMQ installed
from the official repo (http://www.rabbitmq.com/releases/rabbitmq-server),
installed version is 3.6.10.
Logrotate fails with the following message:
/etc/cron.daily/logrotate:
Error: Failed to initialize erlang distribution: {{shutdown,
{failed_to_start_child,
auth,
{{error,
"Error when reading /var/lib/rabbitmq/.erlang.cookie: eacces"},
[{auth,init_cookie,0,
[{file,"auth.erl"},
{line,286}]},
{auth,init,1,
[{file,"auth.erl"},
{line,140}]},
{gen_server,init_it,2,
[{file,
"gen_server.erl"},
{line,365}]},
{gen_server,init_it,6,
[{file,
"gen_server.erl"},
{line,333}]},
{proc_lib,
init_p_do_apply,3,
[{file,"proc_lib.erl"},
{line,247}]}]}}},
{child,undefined,
net_sup_dynamic,
{erl_distribution,
start_link,
[['rabbitmq-cli-24',
shortnames],
false]},
permanent,1000,supervisor,
[erl_distribution]}}.
error: error running shared postrotate script for '/var/log/rabbitmq/*.log '
Digging through audit.log I found a denied access to
/var/lib/rabbitmq/.erlang.cookie.
audit2allow suggests the following two selinux rules to be added in order
for logrotate for rabbitmq to work:
***@***.*** / # grep rabbitmq /var/log/audit/audit.log.1 | audit2allow
#============= logrotate_t ==============
allow logrotate_t rabbitmq_var_lib_t:dir { read write };
allow logrotate_t rabbitmq_var_lib_t:file getattr;
Should the rabbitmq rpm ship with an updated SELinux policy or is this up
to the user to update the policy?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAEQusnVtNiC1kdnDE9kq2uul05hCVXks5sXqq7gaJpZM4OZj_t>
.
--
MK
Staff Software Engineer, Pivotal/RabbitMQ
|
|
logrotate itself shouldn't access rabbitmq_var_lib_t. You should set up a domain transition, instead, so that only processes in the rabbitmq domain access rabbitmq files. See the domain transition chapter on https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-2-files-and-processes for an example... |
|
when logrotate runs it processes /etc/logrotate.d/rabbitmq-server where in the postrotate section it calls rabbitmqctl which opens a new log file. To best of my knowledge it is rabbitmqctl that requires access to the erlang cookie, however, it is invoked by logrotate.
The logrotate script ships in the rabbitmq-server RPM.
root@n1 /var/log # rpm -qf /etc/logrotate.d/rabbitmq-server
rabbitmq-server-3.6.10-1.el7.noarch
… On 14 Aug 2017, at 08:31, Gerald Vogt ***@***.*** ***@***.***>> wrote:
logrotate itself shouldn't access rabbitmq_var_lib_t. You should set up a domain transition, instead, so that only processes in the rabbitmq domain access rabbitmq files.
See the domain transition chapter on https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-2-files-and-processes <https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-2-files-and-processes> for an example...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmp5UgEfYHR558A5QdwzPZ0bWYLJOZ-ks5sX-mwgaJpZM4OZj_t>.
|
|
Which is exactly why you implement domain transition so that rabbitmqctl (or whichever best suited) can operate in the rabbitmq_t domain instead of logrotate_t when called through logrotate. |
|
@gvde as noted above in this comment, if you could provide assistance in crafting a fix it would be completed much sooner. Thanks! |
|
@lukebakken Well, there is a mixup of issues in this one. I use the EPEL 7 version of rabbitmq and I still haven't found the definite solution for that, yet. For the other issues raised here it seems like a transition problem. But I don't use that version of rabbitmq and wouldn't be able to test it. But so far it looks to me like a different problem except that both are SeLinux related... |
|
@gvde - I have tried out the reproduction steps you list here and notice the same issue in my CentOS 7 virtual machine. However, if I use #!/bin/sh
echo "id: `id`"
echo "id -r -u: `id -r -u`"
echo "id -r -g: `id -r -g`"
/sbin/runuser rabbitmq -s /bin/sh -c "id"
/bin/su rabbitmq -s /bin/sh -c "id"Here is the output I get from Here is the SELinux policy applied to If convenient, could you see if switching from |
|
SELinux notes:
After running |
|
These two lines would normally assign a |
|
Thanks @lukebakken I will test it out and report back |
|
On a 64 bit centos7 there should be an equivalence rule /usr/lib64 = /usr/lib which would assign the same labels to files in lib64 as lib. It's best to verify the assigned labels with ls -Z to see if that's really the problem. Check all fcontext rules with Equivalence rules are at the bottom. |
|
Please see my followup comment. I am trying to keep the |
Use /sbin/runuser to execute script as the `rabbitmq` user as this command does not cause issues with SELinux. See #32 for details.
Because the rabbitmq user shell defaults to /bin/false, we must explicitly define a shell when using the runuser command Issue: #32 PR: #40 [#150221349] Signed-off-by: Gerhard Lazu <[email protected]>
|
@michaelklishin I don't need a snapshot. I have modified the script already to use runuser and it works. Thus, as long as the patch implements runuser it's fine. Of course, now I run into #39 :) |
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1426600
During logrotate for rabbitmq-server the call to rabbitmqctl fails with an error on RHEL 7/CentOS 7
The server is still writing into the old log file which has been renamed by logrotate.
The text was updated successfully, but these errors were encountered: