Redis ACL Rule Decoder

Paste an ACL line, from a config file or an ACL SETUSER command, and see what each rule does and what the user ends up with. Both the user prefix and bare rules are accepted.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Decode. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

An application user

What each rule contributes, and what the user ends up able to do

user app on >s3cret ~app:* +@read +@write

Order reverses the meaning

A rule set that reads as restrictive and grants everything

user ops on >s3cret ~* -@dangerous +@all

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Writing `-@dangerous +@all`

    Rules apply strictly left to right, so `+@all` overwrites the revocation and the user has every command. ACL GETUSER shows the resulting permissions rather than the mistake.

    Instead:`+@all -@dangerous`. Grant first, subtract after.

  2. Granting commands without a key pattern

    Keys and commands are independent axes. The user can run everything and touch nothing, and the NOPERM error names the key, which sends people looking in the wrong place.

    Instead:Add `~pattern` alongside the command rules.

  3. Reading nopass as no access

    It means ANY password authenticates, including an empty one. It is unrestricted access for anyone who can reach the port.

    Instead:`off` disables a user. `nopass` opens it.

Rules apply left to right, and that is the whole difficulty

An ACL is not a set of permissions, it is a sequence of edits to one. The order decides the result, and the result is what Redis enforces regardless of how the sequence reads.

+@all after a revocation undoes it

-@dangerous +@all grants everything, because +@all came last. +@all -@dangerous is the restrictive one. Nothing warns about the first form, and ACL GETUSER shows the resulting permission set rather than the mistake, so reviewing the output does not catch it either.

Keys, channels and commands are three independent axes

A user with +@all and no ~ pattern can run every command and touch no keys. The resulting error is NOPERM naming the key, which reads as a key problem rather than a missing grant, and sends people to the wrong place. Since Redis 7.0 the same applies to channels, because acl-pubsub-default changed to resetchannels.

nopass is not the same as no access

nopass means ANY password authenticates, including an empty one. It is unrestricted access for anyone who can reach the port, not a locked account. off is the locked one.

The password forms differ in what leaks

The > form takes clear text, which then exists in the config file, in shell history if it was typed, and in any log that captured the command. The # form takes a SHA-256 hash, so the clear text never appears. ACL GETUSER shows existing password hashes, which is how you convert without knowing the original.

What this cannot see

It reads the rules you paste. It does not know which commands are in which category on your server version, since categories gain commands as Redis adds them, and it cannot tell you whether a key pattern matches your actual keys. ACL DRYRUN on a real server answers the specific question of whether a given user may run a given command on a given key.