Comment 3 for bug 2006484

Okay, further investigation suggests it's a combination of a packaging issue (deliberately?) and the way the charm generates the cookie:

From the package's debian/rabbitmq-server.postinst file:

 # We generate the erlang cookie by ourselves, just to make sure we don't
 # leave the job to erlang that doesn't do it with enough entropy.
 if ! [ -e /var/lib/rabbitmq/.erlang.cookie ] ; then
  OLD_UMASK=$(umask)
  umask 077; openssl rand -base64 -out /var/lib/rabbitmq/.erlang.cookie 42
  umask ${OLD_UMASK}
 else
  # This matches an Erlang generated cookie file: 20 upper case chars
  if grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie ; then
   OLD_UMASK=$(umask)
   umask 077; openssl rand -base64 -out /var/lib/rabbitmq/.erlang.cookie 42
   umask ${OLD_UMASK}
   if [ ""$(ps --no-headers -o comm 1) = "systemd" ] ; then
    if systemctl is-active --quiet rabbitmq-server.service ; then
     systemctl restart rabbitmq-server.service
    fi
   fi
  fi
 fi

A cookie that the charm generates is:

# cat .erlang.cookie
STPUDRGPEHHJDUXOISZO

And the grep command:

# grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie
# echo $?
0

Whereas for a 'new' cookie:

# cat .erlang.cookie
xbU/nSZTfUW8bl24b2ssjCj9Z8EGqwtdqaRVn1TJfjrrYXb/gG1t+0mz

and the grep command:

# grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie
# echo $?
1

Therefore, I'm fairly confident it's caused by the package. From the debian/README this is intentional:

2/ Erlang cookie

Prior to Debian version 3.9.8-3, rabbitmq-server generated an Erlang
"magic cookie" shared secret if one did not exist. This secret is
stored in /var/lib/rabbitmq/.erlang.cookie

However, due to predictable seeds and a non-cryptographic randomizer,
the automatically-generated secret written by Erlang only supplies 20
to 40 bits of entropy. This allows a remote attacker with access to
port 25672 to brute-force the "magic cookie," potentially within
minutes, authenticate as a remote node, and EXECUTE ARBITRARY CODE.

Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a
cryptographically-secure cookie during first installation, mitigating
this vulnerability.

Servers which installed a prior version, and are upgrading to 3.9.8-3
or higher, ARE STILL VULNERABLE, as the package will not regenerate
the secret if it exists already. This is because the secret is
designed to be shared between nodes in a cluster, and thus
regenerating it would break existing clusters.

Operators upgrading from earlier versions of rabbitmq-server are
strongly encouraged to generate a new secret. This can be done via:

    openssl rand -base64 42 >/var/lib/rabbitmq/.erlang.cookie

---

i.e. I don't think the postinst script should be doing this?

Thoughts welcome.