Rabbitmq-server: set_permissions wildcard expansion

[marscher]

Hi,

I'd guess this one is trivial, but I can not figure out why protected (quoted) .* permissions always expands to file names.

I'm trying to invoke the set_permissions calls like in documented in the quick start guide:

rabbitmqctl set_permissions -p myvhost myuser ".*" ".*" ".*"

But the result is the following:

Error: operation set_permissions used with invalid parameter: ["myuser",
                                                               "'.*",".","..",
                                                               ".mkdir",".*'"]

Using version 3.6.10 installed by conda from conda-forge.

I've tried already lots of options of disable expansion in the invoking shell (bash), but somewhere this is "undone" again. I really wonder why this does not seem to be an issue to more people, because expansion is a default feature of this commonly used shell. Please enlighten me! Thanks a lot.

[michaelklishin]

Thank you for your time.

Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. This assumes two things:

1. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team)
2. We have a certain amount of information to work with

We get at least a dozen of questions through various venues every single day, often quite light on details.
At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because of that questions, investigations, root cause analysis, discussions of potential features are all considered to be mailing list material by our team. Please post this to rabbitmq-users.

Getting all the details necessary to reproduce an issue, make a conclusion or even form a hypothesis about what's happening can take a fair amount of time. Our team is multiple orders of magnitude smaller than the RabbitMQ community. Please help others help you by providing a way to reproduce the behavior you're
observing, or at least sharing as much relevant information as possible on the list:

• Server, client library and plugin (if applicable) versions used
• Server logs
• A code example or terminal transcript that can be used to reproduce
• Full exception stack traces (not a single line message)
• rabbitmqctl status (and, if possible, rabbitmqctl environment output)
• Other relevant things about the environment and workload, e.g. a traffic capture

Feel free to edit out hostnames and other potentially sensitive information.

When/if we have enough details and evidence we'd be happy to file a new issue.

Thank you.

[michaelklishin]

Your shell expands it. Why it may be expanding quoted values, I'm not sure.

[lukebakken]

@marscher - I think there's a hint in the error output:

"myuser",
"'.*",
".",
"..",
".mkdir",
".*'"

Notice that the second element in that list is "'.*" - with a single quote, and that the last element is ".*'". I recommend double-checking that you are using actual double-quote characters and haven't copied something like U+201C and U+201D.

Or, change your quoting to use single-quotes:

rabbitmqctl set_permissions -p myvhost myuser '.*' '.*' '.*'

[marscher]

Thank you for your quick responses. I've double checked, that there are no extra quotes, just using single quotes also lead to file name expansion.

[marscher]

I ended up using the web interface to set the permissions...

[lukebakken]

OK. As @michaelklishin said, there must be something awry with your shell or terminal. If this were an issue with rabbitmqctl be assured we would hear about it non-stop as .* is a very common regex.

[marscher]

On 08/11/2017 05:59 PM, Luke Bakken wrote:

OK. As @michaelklishin https://github.com/michaelklishin said, there
must be something awry with your shell or terminal. If this were an
issue with |rabbitmqctl| be assured we would hear about it non-stop as
|.*| is a very common regex.

yes, it is very likely that my shell is borked.

[costrouc]

Have the exact same issue with a the conda forge package

[pcm32]

I also have the issue with the conda forge based installation... I get a weird expansion error:

$ rabbitmqctl set_permissions -p vhost user ".*" ".*" ".*"
Error (argument validation): too many arguments.
Arguments given:
    set_permissions -p vhost user . .. .mkdir . .. .mkdir . .. .mkdir

Usage

rabbitmqctl [--node <node>] [--longnames] [--quiet] set_permissions [--vhost <vhost>] <username> <conf> <write> <read>

[pcm32]

However if I do:

echo ".*"
.*

so I don't think that my shell is expanding the asterisk...

[pcm32]

@michaelklishin could we re-open this issue? Thanks!

[lukebakken]

@pcm32 I suspect that the "conda forge package" installs a script wrapper for rabbitmqctl. Can you grab that file and _attach_ it to your next comment here?

I deleted your previous comment. Please save command output to files and attach the files. Do NOT paste large amounts of text into a comment.

[pcm32]

Here is the wrapper attached
conda_rabbitmqctl_wrapper.sh.txt, thanks @lukebakken for taking a look.

[pcm32]

Setting a set -o noglob on line 28 right before the last exec sorts it out, for this at least, not sure if it would have consequences for other commands where you might want to use the *.

Thanks for pointing me to the wrapper @lukebakken, I hadn't thought of that!

[lukebakken]

Glad that worked for you. That is a bug in the "conda package". If you have time, you should let them know.

[devopsenggineer]

Below commands worked for me

kubectl exec -it $(kubectl get pods -o=name | grep rabbitmq ) -- rabbitmqctl -- add_user testuser testpassword

kubectl exec -it $(kubectl get pods -o=name | grep rabbitmq ) -- rabbitmqctl  set_permissions -p  my_vhost testuser "" ".*" ".*"

[Anthchirp]

Glad that worked for you. That is a bug in the "conda package". If you have time, you should let them know.

Yes, I just had to re-discover this issue myself :smile:
This should now be fixed in conda-forge rabbitmq 3.8.9-2 via https://github.com/conda-forge/rabbitmq-server-feedstock/pull/31

[costrouc]

@Anthchirp thanks for the PR. This was a critical issue for a client I was working with. Can verify that 3.8.9-2 fixes the issue.