Redis ACL Key-Pattern Restrictions and Keyspace-Wide Command Behavior

Direct answer

In Redis ≥ 6.0 a user’s key‑pattern (e.g. ~cache:*) is evaluated for every key that a command touches. Keyspace‑wide commands such as KEYS, SCAN, FLUSHALL, FLUSHDB, DEL with a wildcard, UNLINK, RENAME and MIGRATE are filtered by the ACL: only keys that match at least one of the user’s allowed patterns are considered, and the command’s result or effect is limited to those keys. If no key matches the pattern, the command returns the usual empty result (e.g. 0 for FLUSHALL, an empty list for KEYS) rather than an error, provided the user has the generic permission to run the command. If the user lacks the required command flag (e.g. missing +write for FLUSHALL), Redis replies with NOPERM before any key‑pattern check.

Answers to the specific questions

1. Do SCAN and KEYS respect the pattern? Yes. The server iterates over the keyspace, applies the user’s key‑pattern ACL to each key, and returns only those that match. The command itself is allowed if the user has the +read flag (or the specific +keys flag in newer versions).
2. Can a user with a broad command category (e.g. +@read) reach keys outside its ~pattern? No. Even with +@read, each key accessed by a read command is checked against the user’s patterns; keys outside the pattern cause the command to return NOPERM (for multi‑key commands) or to be omitted from the result (for KEYS/SCAN).
3. How to confirm the effective permissions? Use ACL LIST to see the user’s rules, then test with a command that would expose out‑of‑pattern keys. For example, as the limited user run KEYS * and verify that only keys matching the pattern appear; run FLUSHALL and check that the return value is 0 and that keys outside the pattern remain unchanged (checked with an admin connection).

Confirmed facts

• ACL key‑pattern matching uses the same glob rules as the KEYS command (case‑sensitive, supports *, ?, [...]).
• The pattern filter is applied after the generic command permission check but before any key‑level operation.
• If a command would affect zero matching keys, Redis returns the standard empty response rather than an error.

Likely explanation (behavior that follows from the design)

The ACL engine treats each key individually. For commands that touch many keys, the engine loops over the keyspace, applies the pattern ACL to each key, and either skips the key (for read‑only enumeration) or skips the operation (for write/delete). This design ensures that a user cannot learn about or modify keys outside their namespace, even when using commands that conceptually operate on the whole database.

Verification steps for this case

1. Start a Redis server (version 6.0 or newer).
2. Create a test user:

   ACL SETUSER appuser on >apppass ~cache:* +read +write

3. As appuser, run KEYS * and note the returned list.
4. Run SCAN 0 and verify that only keys matching cache:* appear in the cursor iterations.
5. Run FLUSHALL; the reply should be 0. Re‑check with an admin connection that non‑cache:* keys are unchanged.
6. Remove the write flag and retry FLUSHALL; you should see NOPERM before any key‑pattern evaluation.

Missing diagnostic detail

If you are unsure whether your Redis version is ≥ 6.0, please confirm the version (e.g. redis-server --version) because ACLs do not exist in earlier releases and the behavior described above would not apply.