Testing permissions and discovered user is able to publish to queue that
he does not have write permission to.

Can anyone else duplicate? If so, is this fixed on 2.6.0?

Running RabbitMQ 2.5.1 on debian

Permissions on /:
user configure write read
nf .* ^nf_to_da.*|amq\\.default|test_.* ^da_to_nf.*|test_.*

testing as user nf:
1) publish to nf_to_da queue -> publish successful (correct)
2) read from da_to_nf queue -> read successful (correct)
3) publish to da_to_nf queue -> publish successful! (should be denied) <===4) read from nf_to_da queue -> read denied (correct)


Client is written in perl using Net::RabbitMQ (same results when using
python examples from tutorial)
Logged in as user 'nf'
publish to nf_to_da
...success
publish to da_to_nf (should fail)
...success
consume from da_to_nf
...success
consume from nf_to_da (should fail)
Get failure for queue 'nf_to_da': Consume queue: server channel error
403, message: ACCESS_REFUSED - access to queue 'nf_to_da' in vhost '/'
refused for user 'nf'



Log from RabbitMQ message broker:

=INFO REPORT==== 2-Sep-2011::09:01:58 ==accepted TCP connection on [::]:5672 from 10.1.0.27:43796

=INFO REPORT==== 2-Sep-2011::09:01:58 ==starting TCP connection <0.11704.25> from 10.1.0.27:43796

=INFO REPORT==== 2-Sep-2011::09:01:58 ==closing TCP connection <0.11704.25> from 10.1.0.27:43796


=INFO REPORT==== 2-Sep-2011::09:01:58 ==accepted TCP connection on [::]:5672 from 10.1.0.27:43797

=INFO REPORT==== 2-Sep-2011::09:01:58 ==starting TCP connection <0.11711.25> from 10.1.0.27:43797

=INFO REPORT==== 2-Sep-2011::09:01:58 ==closing TCP connection <0.11711.25> from 10.1.0.27:43797


=INFO REPORT==== 2-Sep-2011::09:01:58 ==accepted TCP connection on [::]:5672 from 10.1.0.27:43798

=INFO REPORT==== 2-Sep-2011::09:01:58 ==starting TCP connection <0.11719.25> from 10.1.0.27:43798

=INFO REPORT==== 2-Sep-2011::09:01:58 ==closing TCP connection <0.11719.25> from 10.1.0.27:43798


=INFO REPORT==== 2-Sep-2011::09:01:58 ==accepted TCP connection on [::]:5672 from 10.1.0.27:43799

=INFO REPORT==== 2-Sep-2011::09:01:58 ==starting TCP connection <0.11733.25> from 10.1.0.27:43799

=ERROR REPORT==== 2-Sep-2011::09:01:58 ==connection <0.11733.25>, channel 1 - error:
{amqp_error,access_refused,
"access to queue 'nf_to_da' in vhost '/' refused for user
'nf'",
'basic.consume'}

=INFO REPORT==== 2-Sep-2011::09:01:58 ==closing TCP connection <0.11733.25> from 10.1.0.27:43799

Search Discussions

  • Matthias Radestock at Sep 3, 2011 at 5:00 am
    Bill,
    On 02/09/11 16:14, Bill Gerrard wrote:
    Testing permissions and discovered user is able to publish to queue that
    he does not have write permission to.
    Technically there is no such thing as publishing to a queue; one always
    publishes to an exchange. Though the default exchange helps create the
    illusion that one can publish to a queue.

    As per http://www.rabbitmq.com/admin-guide.html#access-control,
    publishing only requires write permissions on the exchange.

    Depending on what exactly you want to do, one option might be to

    1) create one fanout exchange per queue, named after the queue, binding
    the queue to that exchange, and

    2) prohibit write access to the default exchange, and

    3) get publishers to publish to the per-queue fanout exchanges, and

    4) restrict write access to the fanout exchanges in order to control who
    can "publish" to what queue


    Regards,

    Matthias.
  • Bill Gerrard at Sep 6, 2011 at 2:14 pm
    Matthias,
    On 09/02/2011 11:00 PM, Matthias Radestock wrote:
    Bill,
    On 02/09/11 16:14, Bill Gerrard wrote:
    Testing permissions and discovered user is able to publish to queue that
    he does not have write permission to.
    Technically there is no such thing as publishing to a queue; one
    always publishes to an exchange. Though the default exchange helps
    create the illusion that one can publish to a queue.

    As per http://www.rabbitmq.com/admin-guide.html#access-control,
    publishing only requires write permissions on the exchange.
    Thank you for the clarification. I will look into using per-queue fanout
    exchanges.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedSep 2, '11 at 3:14p
activeSep 6, '11 at 2:14p
posts3
users2
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase