Hi,
I'd like to tentatively suggest there may be a bug in the process of
qpid-send transferring a message to a broker using AMQP 1.0. This has come
to light because I'm using a fairly locked-down ACL which is intended to
allow clients only exactly the access they require.
The simplified situation is that I have a 0.34 broker with a topic exchange
("test.topic") and an ACL which allows my user to access and publish to the
exchange, something like this:
#start acl
acl allow client@QPID access exchange name=test.topic
acl allow client@QPID publish exchange name=test.topic
acl deny-log all all
#end acl
I'm sending a message to the broker with:
qpid-send -b broker:5671 --connection-options
"{transport:ssl,protocol:amqp1.0}" -a "test.topic" --content-string "hello"
and getting the error message:
qpid-send: Link detached by peer with amqp:unauthorized-access: ACL denied
access request to test.topic from client@QPID
(<snip>/src/qpid/broker/amqp/Authorise.cpp:144)
The broker log shows:
[Security] info qpid.192.168.0.221:5671-192.168.0.221:56953 Authenticated
as client@QPID
[Security] debug ACL: Lookup for id:client@QPID action:access
objectType:exchange name:test.topic with params { }
[Security] debug ACL: checking rule [rule 1 ruleMode = allow props{
name=test.topic }]
[Security] debug ACL: lookup name 'test.topic' matched with rule name
'test.topic'
[Security] debug ACL: Successful match, the decision is:allow
[Security] debug ACL: Lookup for id:client@QPID action:access
objectType:queue name:test.topic with params { }
[Security] debug ACL: No successful match, defaulting to the decision mode
deny-log
Notice that access is correctly approved with object type 'exchange', but
that the process nevertheless continues to try with object type 'queue'
instead, which then fails.
I've tried being explicit with the node type by using the address '
test.topic;{node:{type:exchange}}' but that produced exactly the same
results.
I've found 2 ways to make this work - firstly by changing the protocol to
amqp0-10 in the connection options (this does not allow the node type
specification in the address, but seems to work anyway), and secondly by adding
in an ACL entry to allow access to the non-existent queue "test.topic":
acl allow client@QPID access queue name=test.topic
whereupon the broker log looks like this:
[Security] info qpid.192.168.0.221:5671-192.168.0.221:56955 Authenticated
as client@QPID
[Security] debug ACL: Lookup for id:client@QPID action:access
objectType:exchange name:test.topic with params { }
[Security] debug ACL: checking rule [rule 1 ruleMode = allow props{
name=test.topic }]
[Security] debug ACL: lookup name 'test.topic' matched with rule name
'test.topic'
[Security] debug ACL: Successful match, the decision is:allow
[Security] debug ACL: Lookup for id:client@QPID action:access
objectType:queue name:test.topic with params { }
[Security] debug ACL: checking rule [rule 2 ruleMode = allow props{
name=test.topic }]
[Security] debug ACL: lookup name 'test.topic' matched with rule name
'test.topic'
[Security] debug ACL: Successful match, the decision is:allow
[Security] debug ACL: Lookup for id:client@QPID action:access
objectType:exchange name:test.topic with params { durable=true type=topic }
[Security] debug ACL: checking rule [rule 1 ruleMode = allow props{
name=test.topic }]
[Security] debug ACL: lookup name 'test.topic' matched with rule name
'test.topic'
[Security] debug ACL: Successful match, the decision is:allow
[Security] debug ACL: Lookup for id:client@QPID action:publish
objectType:exchange exchange name:test.topic with routing key
[Security] debug ACL: checking rule [rule 3 ruleMode = allow props{
name=test.topic }]
[Security] debug ACL: Rule: 3 lookup exchange name 'test.topic' matched
with rule name 'test.topic'
[Security] debug ACL: Rule: 3 Successful match, the decision is:allow
I wonder if this is related to this issue:
https://issues.apache.org/jira/browse/QPID-5299, namely the security
concerns about applying ACL rules before revealing the existence of objects.
Have I missed anything? Can this legitimately be called a bug?
Regards
--
*Chris Richardson*, System Architect
c...@fourc.eu
*FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norwaywww.fourc.eu
<http://www.fourc.eu/>*
*Follow us on LinkedIn <http://bit.ly/fourcli>, Facebook
<http://bit.ly/fourcfb>, Google+ <http://bit.ly/fourcgp> and Twitter
<http://bit.ly/fourctw>!*
