You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jakub Scholz <ja...@scholz.cz> on 2015/04/12 21:43:53 UTC
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
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers ACL error
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Chuck,
Correct, in C++ broker also 0-10 closes the session which triggered the ACL
error, but keeps the connection open.
In our case, scanning against the ACL permissions should not reveal
anything surprising (as you said, we list few allowed actions and follow
with deny all all). But IMHO is always better to be safe than sorry. That
said, not closing the connection is for sure not a critical issue which
would cause some real problems. It was more an idea based on seeing what
the Java broker does.
Regards
Jakub
On Mon, Apr 13, 2015 at 5:46 AM, Chuck Rolke <cr...@redhat.com> wrote:
> ----- Original Message -----
> > From: "Jakub Scholz" <ja...@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
>
>
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers
ACL error
Posted by Chuck Rolke <cr...@redhat.com>.
----- Original Message -----
> From: "Jakub Scholz" <ja...@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
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers ACL error
Posted by Jakub Scholz <ja...@scholz.cz>.
Entered as QPID-6492 / https://issues.apache.org/jira/browse/QPID-6492
Thanks.
On Mon, Apr 13, 2015 at 9:33 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 04/13/2015 01:33 PM, Jakub Scholz wrote:
>
>> On Mon, Apr 13, 2015 at 2:30 PM, Gordon Sim <gs...@redhat.com> wrote:
>>
>> Yes, I agree, and that can certainly be done for the ACLs as well.
>>>
>>
>>
>> Great. Should I enter a JIRA?
>>
>> Yes, that would be great, thanks!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers
ACL error
Posted by Gordon Sim <gs...@redhat.com>.
On 04/13/2015 01:33 PM, Jakub Scholz wrote:
> On Mon, Apr 13, 2015 at 2:30 PM, Gordon Sim <gs...@redhat.com> wrote:
>
>> Yes, I agree, and that can certainly be done for the ACLs as well.
>
>
> Great. Should I enter a JIRA?
>
Yes, that would be great, thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers ACL error
Posted by Jakub Scholz <ja...@scholz.cz>.
On Mon, Apr 13, 2015 at 2:30 PM, Gordon Sim <gs...@redhat.com> wrote:
> Yes, I agree, and that can certainly be done for the ACLs as well.
Great. Should I enter a JIRA?
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers
ACL error
Posted by Gordon Sim <gs...@redhat.com>.
On 04/13/2015 12:26 PM, Jakub Scholz wrote:
> On Mon, Apr 13, 2015 at 1:13 PM, Gordon Sim <gs...@redhat.com> wrote:
>
>> Even in that case, the broker issues an attach, then detaches. The one
>> differences in terms of the c++ broker's behaviour is that in the not-found
>> case, the broker sets the source/target to null.
>
>
> Correct, even in that case it does the attach before the detach. But the
> source/target=null can/should be used by the client as indication that a
> detach will follow. At least that would be my understanding of the 1.0 spec.
Yes, I agree, and that can certainly be done for the ACLs as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers ACL error
Posted by Jakub Scholz <ja...@scholz.cz>.
On Mon, Apr 13, 2015 at 1:13 PM, Gordon Sim <gs...@redhat.com> wrote:
> Even in that case, the broker issues an attach, then detaches. The one
> differences in terms of the c++ broker's behaviour is that in the not-found
> case, the broker sets the source/target to null.
Correct, even in that case it does the attach before the detach. But the
source/target=null can/should be used by the client as indication that a
detach will follow. At least that would be my understanding of the 1.0 spec.
Re: Does Qpid C++ behave reasonably when a AMQP 1.0 link triggers
ACL error
Posted by Gordon Sim <gs...@redhat.com>.
On 04/12/2015 08:43 PM, Jakub Scholz wrote:
> 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.
Even in that case, the broker issues an attach, then detaches. The one
differences in terms of the c++ broker's behaviour is that in the
not-found case, the broker sets the source/target to null.
> 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
Access permission is checked before resolving the node, so without
permission to access a node of a given name, you cannot determine
whether or not a node of that name exists.
> For comparison, the Java broker seems to simply close the connection
> without answering the attach. That is IMHO also not a bad idea.
Yes, that is a fair point. As Chuck mentioned, in 0-10 all errors tended
to end up closing the session which was often felt to be overly harsh.
This wasn't specifically for ACLs though and I have a lot of sympathy
with the view that for security related errors, harsh is good.
One possibility would be to change the default behaviour to close the
connection on ACL violations, but have broker level a configuration
option to get the current behaviour if required.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org