activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.com>
Subject Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Date Thu, 14 May 2015 16:11:57 GMT
> However, it is doubtful this is the way any broker will ever be run for real.

Yes, of course.

As I see it, the default configuration is for users (mostly developers) who want to start
up a broker quickly, run a few examples, look at the console, etc. All that would typically
be done locally since that is the simplest, fastest use-case.  To move beyond that use-case
(e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation
and come to understand more of how the broker works, the importance of security, etc.

I don't think it's common for users to unzip the broker and deploy to production with no changes.
IMO, the broker configuration is typically tailored for the application and environment. Binding
the network transports to the proper interface is just part of that process.


> It's like having a web server start up without the ability to server web pages by default.

If the web server was 100% read-only then I'd probably be find with it binding to a public
interface by default. However, if there was any way for remote users to impact my machine
through that server (beyond a DOS attack) then I would want the server to bind to localhost
by default or be secured with e.g. a username/password.  That just seems like common sense
to me.

In short, I think we should take a pretty conservative approach with our user's security.
 I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current
configuration is too liberal.  If we were to bind to 0.0.0.0 by default I'd want to either
remove the default user account altogether or change it so that the default user could only
consume messages (i.e. couldn't produce messages, create queues, or perform management operations).


Justin

----- Original Message -----
From: "Jim Gomes" <e.semog@gmail.com>
To: "ActiveMQ Dev" <dev@activemq.apache.org>
Sent: Thursday, May 14, 2015 10:28:15 AM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)

If it was done on purpose for security reasons, that's cool. However, it is
doubtful this is the way any broker will ever be run for real. The whole
purpose of a broker is to integrate disparate systems. It's like having a
web server start up without the ability to server web pages by default.
Kind of silly.

Anyway, I will log the bug with the NMS clients, and I do think the release
should be held up because of this problem. It's a show-stopper for NMS
clients.  Here's the server exception being thrown:

ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.IllegalStateException: Cannot handle command: ConsumerControl
{commandId = 0, responseRequired = false, consumerId =
ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
false, start = false, flush = false, prefetch = 32766, destination =
topic://UnitTest.Status}
    at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
    at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]



On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jbertram@apache.com> wrote:

> IMO the broker correctly binds to localhost only and does not, by default,
> allow connections from remote machines.  This is a simple security/sanity
> measure to prevent access to default (i.e. unsecured) instances.
>
> The merit of this configuration is obviously up for debate, but it's worth
> noting it was done on purpose.
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <e.semog@gmail.com>
> To: "ActiveMQ Dev" <dev@activemq.apache.org>
> Sent: Thursday, May 14, 2015 10:05:55 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mtaylor@redhat.com>
> wrote:
>
> > Hello all.
> >
> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> > initial RC feedback from community members.
> >
> > This is a first release of the Artemis project with protocol support for
> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >
> > The release notes can be found here:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >
> > The binary distributions can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The source archives can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >
> > The source tag:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.0.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> > Martyn
> >
>

Mime
View raw message