activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bhartsb <>
Subject Re: Correct way to removeDestinations()
Date Tue, 15 May 2007 20:52:34 GMT

The reasons we need to delete were given as item 3 and 4.  So will the method
Andrew gave work?   The method was: "add another method to AbstractRegion
class, called removeDestinations(List<String> destsToRemove) that would
remove destinations which match the provided names in one single
acquire-release-destinations-mutex step, and thus to avoid waiting for
destinationsMutex during one by one deletion of destinations. "

Regarding security, am I incorrect in thinking that giving untrusted clients
the credentials to access the AMQ broker and (dynamically) create queues is
a security risk?  If I have thousands of clients and any hacker acquires
these credentials then they can stage an attack on the AMQ.  

My business case is such that regular queues are the best fit, and surely
other people working with AMQ, who are using regular queues widely (meaning
AMQ is available over the Internet), are taking a security risk of attack
with the current implementation.  Am I wrong in my thinking?

James.Strachan wrote:
> On 5/15/07, bhartsb <> wrote:
>> We have a couple of issues that seem to preclude using temporary queues:
>> 1.  Our C++ clients that use the queues are utilizing STOMP to do so (we
>> can't afford the time to retrofit the C++ apps for openwire at this
>> juncture).  STOMP as I understand does not support temporary queues.
>> 2.  Our C++ clients may temporarily lose a connection to the queues, but
>> reconnect quickly.  In this case we don't want to lose any messages.  It
>> seems from posts that a loss of connection would mean that the msgs in
>> the
>> queues (or still being added) are lost, because the queue connection
>> would
>> not be re-established.  (Note: if the connection is lost for a long
>> period
>> then we do want to create a new queue).
>> 3.  We have our server telling the client applications, what queues to
>> connect to.  The Clients have no knowledge themselves of the queue they
>> need
>> to connect to, and it can be that a producer will connect before a
>> consumer
>> or vice versa.
>> 4.  We don't want client applications to be able to create queues
>> themselves
>> (only publish or consume).  If we did allow them create/destroy
>> priviledge
>> then we would have to give the clients the proper JAAS credentials to
>> allow
>> this.  But the client apps. will be in the public domain.  If they have
>> such
>> credentials then there is a risk that a hacker could get one Client's
>> credentials and gain access to the AMQ broker.  This leaves the AMQ
>> vulnerable to attack.  This is not a risk we want to take.
>> Now if I am wrong about 4 being a security/attack risk, then we could
>> have
>> the server pass the temporary queue name to the producer and consumer
>> apps.
>> But am I wrong?
>> Finally, you mentioned to Andrew that AMQ queues are dynamic, but I don't
>> see this as being the case if they can't be programatically deleted.  I
>> assume you weren't just talking about temporary queues when you said
>> queues
>> are dynamic.
> Any messaging client can talk to any new dynamic destination whenever
> they like (assuming the security allows this) - there is no
> administration required to create a queue - thats why I said they were
> dynamic.
>> Please respond if you can to this and Andrews' prior question about his
>> method of deleting queues (see his last post), and thank you.
> So i still don't get why you insist on deleting queues, rather than
> just purging them.
> -- 
> James
> -------

View this message in context:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message