fix: write Erlang cookie to disk for CLI tool authentication - #59
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves an authentication issue for RabbitMQ CLI tools when used within a Docker Compose environment. By ensuring the Erlang cookie is properly persisted to disk with appropriate permissions, it allows Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly addresses an authentication issue with RabbitMQ CLI tools in a Docker environment by writing the Erlang cookie to disk. The overall logic is sound. I have one suggestion to improve the robustness of the entrypoint script by making its error handling more explicit, which will aid in debugging potential file permission issues.
| # widen permissions before overwriting, then lock back down. | ||
| cookie_file="${RABBITMQ_MNESIA_DIR:-/var/lib/rabbitmq}/.erlang.cookie" | ||
| if [ -f "${cookie_file}" ]; then | ||
| chmod 600 "${cookie_file}" 2>/dev/null || true |
There was a problem hiding this comment.
Suppressing errors from chmod with 2>/dev/null || true can hide underlying problems, such as incorrect file ownership. This makes debugging more difficult if the script fails later at the printf command. Since the if [ -f ... ] guard on the preceding line already prevents chmod from failing on a non-existent file, the error suppression is not necessary and it's safer to let the script fail immediately if chmod encounters an unexpected error.
| chmod 600 "${cookie_file}" 2>/dev/null || true | |
| chmod 600 "${cookie_file}" |
There was a problem hiding this comment.
Pull request overview
Ensures RabbitMQ CLI tools executed via docker compose exec can authenticate by persisting the Erlang cookie to disk during container startup (instead of relying on an env var only visible to PID 1).
Changes:
- Writes
RABBITMQ_ERLANG_COOKIEto an on-disk.erlang.cookiefile at startup. - Temporarily relaxes permissions on an existing cookie to allow overwrite, then locks it back down to
0400.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if [ -f "${cookie_file}" ]; then | ||
| chmod 600 "${cookie_file}" 2>/dev/null || true | ||
| fi | ||
| printf '%s' "${cookie}" > "${cookie_file}" | ||
| chmod 400 "${cookie_file}" | ||
|
|
There was a problem hiding this comment.
If the cookie file already exists and you chmod it to 0600, then a subsequent failure while writing (disk full, permission issue, etc.) will cause the script to exit (set -e) and leave the cookie less restricted than intended. Consider writing via a temporary file + atomic rename and/or using a trap to always restore permissions to 0400 on exit.
| if [ -f "${cookie_file}" ]; then | |
| chmod 600 "${cookie_file}" 2>/dev/null || true | |
| fi | |
| printf '%s' "${cookie}" > "${cookie_file}" | |
| chmod 400 "${cookie_file}" | |
| tmp_cookie_file="${cookie_file}.tmp.$$" | |
| printf '%s' "${cookie}" > "${tmp_cookie_file}" | |
| chmod 400 "${tmp_cookie_file}" | |
| mv -f "${tmp_cookie_file}" "${cookie_file}" |
| # The env var is only visible to PID 1; exec'd shells read the file. | ||
| # The file may already exist read-only (0400) from a previous run, so | ||
| # widen permissions before overwriting, then lock back down. | ||
| cookie_file="${RABBITMQ_MNESIA_DIR:-/var/lib/rabbitmq}/.erlang.cookie" |
There was a problem hiding this comment.
Cookie location: Erlang CLI tools generally read the cookie from the invoking user’s home directory ("$HOME/.erlang.cookie"). Using RABBITMQ_MNESIA_DIR here can write the cookie somewhere else if that env var is set, which would still break docker compose exec rabbitmqctl .... Consider basing the path on $HOME (or explicitly /var/lib/rabbitmq) instead of the mnesia dir.
| cookie_file="${RABBITMQ_MNESIA_DIR:-/var/lib/rabbitmq}/.erlang.cookie" | |
| cookie_file="${HOME:-/var/lib/rabbitmq}/.erlang.cookie" |
| fi | ||
| printf '%s' "${cookie}" > "${cookie_file}" | ||
| chmod 400 "${cookie_file}" |
There was a problem hiding this comment.
The cookie file is created with whatever the current umask allows, and only tightened afterward. That can briefly create a world-readable cookie (e.g., umask 022 -> 0644) during startup. Consider setting a restrictive umask (as done in other entrypoints in this repo) before writing the cookie so it’s never created with broader perms.
| fi | |
| printf '%s' "${cookie}" > "${cookie_file}" | |
| chmod 400 "${cookie_file}" | |
| fi | |
| old_umask=$(umask) | |
| umask 077 | |
| printf '%s' "${cookie}" > "${cookie_file}" | |
| chmod 400 "${cookie_file}" | |
| umask "${old_umask}" |
Summary
$RABBITMQ_MNESIA_DIR/.erlang.cookieduring container startup so that CLI tools (rabbitmqctl,rabbitmq-diagnostics) invoked viadocker compose execcan authenticate with the brokerContext
The RabbitMQ entrypoint exports
RABBITMQ_ERLANG_COOKIEas an environment variable, but this is only visible to PID 1. When CLI tools are invoked viadocker compose exec, they spawn a new shell that reads the cookie from~/.erlang.cookieon disk. Without this fix, CLI tools fail with "Invalid challenge reply" errors.Test plan
rabbitmq-overviewsucceeds (CLI tool authentication works)rabbitmq-plugins -elists all enabled pluginsrabbitmq-exportexports definitions via management API