为什么Redis 6.0引入ACL权限控制_设定用户级别的命令访问限制

Redis 6.0引入ACL是为解决旧版单密码机制下权限无法隔离的根本问题：一个密码即拥有所有命令、所有键、所有数据库的完全控制权；ACL通过用户粒度的三要素（启用状态on、有效密码、显式命令权限）和glob风格键模式（~pattern），实现命令与键空间的精细化、可持久化（ACL SAVE需aclfile路径正确且可写）权限分离管控。

Redis 6.0 引入 ACL 不是为了“增强功能”，而是为了解决旧版单密码机制下根本无法隔离权限的现实问题：一个密码 = 所有命令 + 所有键 + 所有数据库。只要拿到密码，就能执行 FLUSHALL、KEYS *、DEBUG SEGFAULT，甚至订阅任意 Pub/Sub 频道。

这在多租户、微服务共用 Redis 实例的场景中极其危险——项目 A 的缓存键 user:123 和项目 B 的敏感数据 payment:txn_456 存在同一实例里，却共享同一套认证凭证。

ACL 的核心价值，是把「谁可以运行什么命令」「谁可以读写哪些键」这两件事，真正拆开控制，落到具体用户粒度。

---

ACL 用户权限由三部分组成，缺一不可

一个用户要能正常工作，必须同时满足以下三项配置，否则连接成功但命令被拒：

• on：用户状态必须启用（off 状态下即使密码正确也拒绝认证）
• 至少一个有效密码：>password（明文）或 #hash（SHA256 哈希），不能只写 nopass（除非你明确允许无密登录）
• 显式授予命令权限：+@read、+get、+@all 等；默认新建用户是 -@all（全拒）

例如，只执行 ACL SETUSER alice on >p1pp0，用户 alice 仍无法执行任何命令——因为没给命令权限。必须补上 +@read 或类似规则。

---

键权限（~pattern）不是通配符补丁，而是正则匹配引擎

ACL 的键模式用 ~ 前缀，底层是 glob 风格匹配（非完整正则），但支持常见通配：

• ~user:* → 匹配 user:1、user:profile:abc
• ~order/202[4-6]/* → 匹配 order/2025/123，但不匹配 order/2023/456
• ~* → 允许所有键（等价于旧版行为）
• ~cache:img:* ~cache:json:* → 多个模式需分开写，用空格分隔

注意：KEYS * 这类扫描命令本身受命令权限控制；即使有 ~* 键权限，若未授予 +keys，该命令仍被拒绝。键权限只约束「对已知键的操作」，不自动放开元操作。

---

ACL SAVE 不等于“永久生效”，它依赖 redis.conf 可写且路径正确

运行时执行的 ACL SETUSER 只驻留在内存。重启后丢失，除非调用 ACL SAVE。但它不是写进任意文件，而是覆盖 redis.conf 中的 aclfile 指定路径（默认是 users.acl，而非主配置文件本身）。

• 若 redis.conf 里没配 aclfile /etc/redis/users.acl，ACL SAVE 会静默失败（返回 OK 但实际没保存）
• 若 /etc/redis/ 目录 Redis 进程无写权限，ACL SAVE 报错：(error) ERR Error writing ACL file: Permission denied
• 修改后必须确保 aclfile 路径在 redis.conf 中存在且可写，再 ACL SAVE，最后 CONFIG REWRITE（可选）或重启验证

最容易被忽略的一点：很多部署直接用容器或 systemd 启动，redis.conf 往往挂载为只读，ACL SAVE 看似成功，实则落盘失败——下次重启就回到初始状态。