qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers ACL error
Date Mon, 13 Apr 2015 03:46:51 GMT
----- Original Message -----
> From: "Jakub Scholz" <jakub@scholz.cz>
> To: users@qpid.apache.org
> Sent: Sunday, April 12, 2015 3:43:53 PM
> Subject: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers ACL error
> 
> Hi,
> 
> I noticed that the current implementation of the C++ broker (0.32) does
> following when the link attach triggers ACL error:
> 2015-04-12 20:54:30 [Protocol] trace
> [qpid.192.168.1.174:10000-192.168.1.241:63318]: 1 <- @attach(18)
> [name="qpid-jms:receiver:ID:JAkub-MBP-63317-1428864868672-0:1:1:1:broadcast.ABCFR_ABCFRALMMACC1.WorkflowX",
> handle=0, role=true, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40) [address="broadcast.ABCFR_ABCFRALMMACC1.WorkflowX",
> durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false,
> default-outcome=@modified(39) [delivery-failed=true,
> undeliverable-here=false], outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> :"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"],
> capabilities=@PN_SYMBOL[:queue]], target=@target(41) []]
> 2015-04-12 20:54:30 [Security] info ACL Deny id:ABCFR_ABCFRALMMACC1@QPID0000
> action:access ObjectType:queue Name:broadcast.ABCFR_ABCFRALMMACC1.WorkflowX
> 2015-04-12 20:54:30 [Protocol] error Error on attach: ACL denied access
> request to broadcast.ABCFR_ABCFRALMMACC1.WorkflowX from
> ABCFR_ABCFRALMMACC1@QPID0000
> (/home/scholzj/amqp/qpid-cpp-0.32/src/qpid/broker/amqp/Authorise.cpp:144)
> 2015-04-12 20:54:30 [Protocol] trace
> [qpid.192.168.1.174:10000-192.168.1.241:63318]: 1 -> @attach(18)
> [name="qpid-jms:receiver:ID:JAkub-MBP-63317-1428864868672-0:1:1:1:broadcast.ABCFR_ABCFRALMMACC1.WorkflowX",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="broadcast.ABCFR_ABCFRALMMACC1.WorkflowX",
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> 2015-04-12 20:54:30 [Protocol] trace
> [qpid.192.168.1.174:10000-192.168.1.241:63318]: 1 -> @detach(22) [handle=0,
> closed=true, error=@error(29) [condition=:"amqp:unauthorized-access",
> description="ACL denied access request to
> broadcast.ABCFR_ABCFRALMMACC1.WorkflowX from ABCFR_ABCFRALMMACC1@QPID0000
> (/home/scholzj/amqp/qpid-cpp-0.32/src/qpid/broker/amqp/Authorise.cpp:144)"]]
> 2015-04-12 20:54:30 [Protocol] trace
> [qpid.192.168.1.174:10000-192.168.1.241:63318]: 1 <- @detach(22) [handle=0,
> closed=true]
> 
> If I read this correctly, it seems to first confirm the attach and only
> then it does the detach with the error. A client application seems to
> confused into thinking that the attach was fine, while in reality the
> attach wasn't fine.
> 
> I was wondering whether it wouldn't be more clean to refuse the attach in
> the same way as it is done when the ACL rights are OK but the node doesn't
> exist. I know that the AMQP 1.0 spec is quite specific when it says that
> the refusing of the link should be used when the terminus doesn't exist.
> But at the end, when the connected client doesn't have rights to access the
> terminus, it is as if it doesn't exist, or? :-o
> 
> For comparison, the Java broker seems to simply close the connection
> without answering the attach. That is IMHO also not a bad idea. On the C++
> broker I can today open one connection and run a "brute force scan"
> checking what I can do and what I cannot do. Would the connection be closed
> after ACL error, additional measures can be used to prevent / slow down
> such behavior (for example most of my brokers have firewall in front of
> them which allows clients to establish only very limited number of
> connections within one minute)
> 
> Thanks & Regards
> Jakub
> 

If I recall in AMQP 0-10 the protocol was much less forgiving of link:
errors. When a link had an error then the session was closed and all 
the other activity on that session was lost. AMQP 1.0 is more 
forgiving and a link error keeps the session and other links alive.

How do you have your ACLs set up? The broker checks whether a user
has rights to a node before checking that the node exists. If the ACL
grants specific rights and then follows up with a deny all then the
user probe won't get very far.

-Chuck

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message