Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of crolke@redhat.com designates
 209.132.183.25 as permitted sender)
Date: Sun, 12 Apr 2015 23:46:51 -0400 (EDT)
From: Chuck Rolke <crolke@redhat.com>
To: users@qpid.apache.org
Message-ID: <545461302.14352794.1428896811443.JavaMail.zimbra@redhat.com>
In-Reply-To: 
 <CAOhBXQ5zT_rvGNEhUucAsWEcO5F=1F6tYUS8bm4NhEb=8Nh9mA@mail.gmail.com>
References: 
 <CAOhBXQ5zT_rvGNEhUucAsWEcO5F=1F6tYUS8bm4NhEb=8Nh9mA@mail.gmail.com>
Subject: Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers
 ACL error
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers
 ACL error
Thread-Index: ExDvOxd9sUSb9j180ej9/CDfpACxbQ==

----- 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