An application user
What each rule contributes, and what the user ends up able to do
user app on >s3cret ~app:* +@read +@write
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
What each rule contributes, and what the user ends up able to do
user app on >s3cret ~app:* +@read +@write
A rule set that reads as restrictive and grants everything
user ops on >s3cret ~* -@dangerous +@all
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
-@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.
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 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 > 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.
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.