3

I am using fusemq, the C wrapper for ActiveMQ-CPP.

The problem is I am using the broker with an Apache server module. It is supposed to send a message to the broker so another program can consume it. I have a script that tests all of this and I have logging in my module that tells me if the message was sent successfully. When Apache is started normally as root and ActiveMQ is started as root, my script gets stuck. The traceback says that it was still waiting for a response. I noticed in my logs that the module gets stuck at creating a default session with the broker. When I step through the module in GDB under these same circumstances the message is sent successfully and the admin panel says there is a message in my queue. When the module runs it does everything as the apache user so I thought that was the problem. So I start the server normally and run ActiveMQ as apache. When I do that my logs tell me the message is sent successfully, the script completes, but I am unable to access the admin panel.

activemq.log output from the 503:

2013-05-28 13:47:51,823 | WARN  | Committed before 503 null | org.eclipse.jetty.server.Response | qtp1146944158-23
2013-05-28 13:47:51,824 | WARN  | /admin/ | org.eclipse.jetty.server.AbstractHttpConnection | qtp1146944158-23
java.lang.IllegalStateException: Committed
     at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1126)
     at org.eclipse.jetty.server.Response.sendError(Response.java:313)
     at org.eclipse.jetty.server.Response.sendError(Response.java:415)
     at org.eclipse.jetty.server.handler.ContextHandler.checkContext(ContextHandler.java:820)
     at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:916)
     at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
     at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
     at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:521)
     at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
     at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
     at org.eclipse.jetty.server.Server.handle(Server.java:363)
     at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:483)
     at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:920)
     at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:982)
     at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
     at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
     at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
     at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)
     at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)
     at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
     at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
     at java.lang.Thread.run(Thread.java:722)

Edit: I am now rerunning my script against the server while ActiveMQ is running as apache and server is root and the script hangs. It is getting stuck at creating a default session. When I step through in GDB it still works though...

Edit: I ran setenforce 0 and everything worked. Not sure why that would be. Any ideas?

Edit: I ran ausearch -m avc -ts 05/30/2013 and this was the output -

time->Tue Jun 4 08:47:40 2013

type=SYSCALL msg=audit(1370357260.183:29896): arch=c000003e syscall=21 success=no exit=-13 a0=c050b0 a1=7 a2=20 a3=a0 items=0 ppid=2618 pid=2633 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1370357260.183:29896): avc:  denied  { read } for  pid=2633 comm="gdm-session-wor" name="root" dev=dm-0 ino=1835009 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
  • run `ausearch -m avc -ts today` or an appropriate time frame (check `ausearch` manual page) to look for AVC denials, filter the output through `audit2allow` and review the it. Further actions should be taken depending on the result of the previous commands. – dawud May 30 '13 at 19:53
  • Is it possible to create a policy in SE Linux that allows for Apache to communicate on a certain port (61616 for ActiveMQ) without being blocked? – thaweatherman May 30 '13 at 21:10
  • Yes. Not even a policy, maybe it is just setting the right permissions on a port. Check `semanage port -l | grep ^http` for a hint. But I need to see the actual AVC denials to say for sure. – dawud May 31 '13 at 20:40
  • @dawud Added the output from running ausearch – thaweatherman Jun 04 '13 at 15:01
  • Not related to AMQ, as `audit2allow` translates this as XDM failing to read a dir: `allow xdm_t admin_home_t:dir read;` – dawud Jun 04 '13 at 15:12
  • @dawud I added ports 8161, 61616, and 61613 to the allowed list for http_port_t and everything works now. If you want to submit an answer about semanage port -a -t http_port_t -p tcp [port] then I will accept it – thaweatherman Jun 04 '13 at 15:16
  • Please document your findings and the procedure you followed in an answer. – dawud Jun 04 '13 at 15:23

1 Answers1

1

Well I managed to figure out the problem in case anyone who stumbles on this is curious.

I enabled selinux again and added ports 61616 (port for openwire connections), 61613 (port for stomp connections), and 8161 (port for admin console) to the allow list for http_port_t.

I used the command:

semanage port -a -t http_port_t -p tcp [port number]