[jira] [Commented] (AMQ-5141) Message expiry that is done as part of a removeSubscription command should not use the clients credentials.

2014-04-11 Thread Torsten Mielke (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966427#comment-13966427
 ] 

Torsten Mielke commented on AMQ-5141:
-

Don't have a Unit test at hand but could build one if time permits.

 Message expiry that is done as part of a removeSubscription command should 
 not use the clients credentials.
 ---

 Key: AMQ-5141
 URL: https://issues.apache.org/jira/browse/AMQ-5141
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.9.0
Reporter: Torsten Mielke
  Labels: DLQ, authorization, expiry, security

 If the broker handles a RemoveInfo command it may also kick off a message 
 expiry check for (I presume) any prefetched messages. If messages are to be 
 expired they get sent to ActiveMQ.DLQ by default. See stack trace in next 
 comment.
 If the broker is security enabled with authorization turned on and messages 
 get sent to DLQ as a result of the expiry check then the broker uses the 
 client's security context when sending the messages to DLQ. 
 This implies the client user needs to have write access to ActiveMQ.DLQ. 
 As this may happen with any other client, all client users will require write 
 access to ActiveMQ.DLQ, which may not be appropriate from a security point of 
 view. 
 The broker regularly runs an expiry check and uses a broker internal security 
 context for this task. In my opinion this same broker internal security 
 context should be used when expiring messages as part of the RemoveInfo 
 command. The broker should not use the client's security context. 
 [1]
 The current behavior can raise the following SecurityException if the client 
 user does not have write access to ActiveMQ.DLQ
 {code}
 2014-04-11 08:11:22,229 | WARN  | 2.38:61201@61616 | RegionBroker | 
 ivemq.broker.region.RegionBroker  703 | 
 105 - org.apache.activemq.activemq-osgi - 5.8.0.redhat-60024 | Caught an 
 exception sending to DLQ: Message 
 ID:S930A3085-50865-635327964441522304-1:1:363:2:1 dropped=false acked=false 
 locked=true
 java.lang.SecurityException: User Test is not authorized to write to: 
 queue://ActiveMQ.DLQ
   at 
 org.apache.activemq.security.AuthorizationBroker.send(AuthorizationBroker.java:197)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:135)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.util.BrokerSupport.doResend(BrokerSupport.java:68)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.util.BrokerSupport.resendNoCopy(BrokerSupport.java:38)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.region.RegionBroker.sendToDeadLetterQueue(RegionBroker.java:691)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.advisory.AdvisoryBroker.sendToDeadLetterQueue(AdvisoryBroker.java:413)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.MutableBrokerFilter.sendToDeadLetterQueue(MutableBrokerFilter.java:274)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.util.RedeliveryPlugin.sendToDeadLetterQueue(RedeliveryPlugin.java:132)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.MutableBrokerFilter.sendToDeadLetterQueue(MutableBrokerFilter.java:274)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.region.RegionBroker.messageExpired(RegionBroker.java:659)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at

[jira] [Commented] (AMQ-5141) Message expiry that is done as part of a removeSubscription command should not use the clients credentials.

2014-04-11 Thread Torsten Mielke (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966450#comment-13966450
 ] 

Torsten Mielke commented on AMQ-5141:
-

Here are two possible workarounds:
1)
The quick solution is to grant write permissions to user 'Test' but potentially 
other users could be affected as well and may also need write permissions for 
ActiveMQ.DLQ. In the worst case all users may require write permissions to 
ActiveMQ.DLQ.

2)
In case you don't care about these expired messages you can also configure the 
broker to simply discard expired messages using this configuration within the 
policyEntry config

deadLetterStrategy
  sharedDeadLetterStrategy processExpired=false /
/deadLetterStrategy

as per http://activemq.apache.org/message-redelivery-and-dlq-handling.html. 
Then the permission problem won't arise.


 Message expiry that is done as part of a removeSubscription command should 
 not use the clients credentials.
 ---

 Key: AMQ-5141
 URL: https://issues.apache.org/jira/browse/AMQ-5141
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.9.0
Reporter: Torsten Mielke
  Labels: DLQ, authorization, expiry, security

 If the broker handles a RemoveInfo command it may also kick off a message 
 expiry check for (I presume) any prefetched messages. If messages are to be 
 expired they get sent to ActiveMQ.DLQ by default. See stack trace in next 
 comment.
 If the broker is security enabled with authorization turned on and messages 
 get sent to DLQ as a result of the expiry check then the broker uses the 
 client's security context when sending the messages to DLQ. 
 This implies the client user needs to have write access to ActiveMQ.DLQ. 
 As this may happen with any other client, all client users will require write 
 access to ActiveMQ.DLQ, which may not be appropriate from a security point of 
 view. 
 The broker regularly runs an expiry check and uses a broker internal security 
 context for this task. In my opinion this same broker internal security 
 context should be used when expiring messages as part of the RemoveInfo 
 command. The broker should not use the client's security context. 
 [1]
 The current behavior can raise the following SecurityException if the client 
 user does not have write access to ActiveMQ.DLQ
 {code}
 2014-04-11 08:11:22,229 | WARN  | 2.38:61201@61616 | RegionBroker | 
 ivemq.broker.region.RegionBroker  703 | 
 105 - org.apache.activemq.activemq-osgi - 5.8.0.redhat-60024 | Caught an 
 exception sending to DLQ: Message 
 ID:S930A3085-50865-635327964441522304-1:1:363:2:1 dropped=false acked=false 
 locked=true
 java.lang.SecurityException: User Test is not authorized to write to: 
 queue://ActiveMQ.DLQ
   at 
 org.apache.activemq.security.AuthorizationBroker.send(AuthorizationBroker.java:197)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:135)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.util.BrokerSupport.doResend(BrokerSupport.java:68)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.util.BrokerSupport.resendNoCopy(BrokerSupport.java:38)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.region.RegionBroker.sendToDeadLetterQueue(RegionBroker.java:691)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.advisory.AdvisoryBroker.sendToDeadLetterQueue(AdvisoryBroker.java:413)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.BrokerFilter.sendToDeadLetterQueue(BrokerFilter.java:262)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.MutableBrokerFilter.sendToDeadLetterQueue(MutableBrokerFilter.java:274)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at 
 org.apache.activemq.broker.util.RedeliveryPlugin.sendToDeadLetterQueue(RedeliveryPlugin.java:132)[105:org.apache.activemq.activemq-osgi:5.8.0.redhat-60024]
   at