Redis ACL SETUSER resetkeys 为什么会清空已有键模式

会。resetkeys 的语义不是“在原有键模式后面追加一条”，而是先清空该用户已有的键模式规则，再应用本次命令中给出的模式。因此，原来允许访问 ~tenant:42:*，随后执行 ACL SETUSER app resetkeys ~tenant:43:* 后，42 这组模式就不再属于用户 app 的键权限。它影响的是键模式，不会自动重置命令权限。

官方地址：https://redis.io/docs/latest/commands/acl-setuser/

Redis ACL 的键模式权限与 resetkeys 边界

先把保护资产分成两层：键模式决定用户能触碰哪些键，命令权限决定用户能执行哪些 Redis 命令。例如 app 可以保留 GET、SET，但只允许访问 ~tenant:42:*。resetkeys 只进入前一层，不能当作命令权限的重置开关。

为什么一次 SETUSER 会让旧模式消失

可以把它看成“替换集合”操作。已有规则是 ~tenant:42:* 和 ~shared:* 时，下面的写法只留下新的租户模式：

# 这条命令会清空 app 原有的键模式，再写入新模式
redis-cli ACL SETUSER app resetkeys '~tenant:43:*'

# 读取用户规则快照；这里关注 keys 字段，不把它当作命令授权结果
redis-cli ACL GETUSER app

所以“命令返回 OK”只说明规则修改被接受，不代表旧模式仍然存在。最常见的攻击路径不是 Redis 自己删除了键，而是应用账号突然失去原租户键的访问资格，随后出现 NOPERM，运维却误判为缓存丢失。

把键模式当成完整集合一次替换

如果目标是保留旧范围并加入新范围，就在同一次命令里写全集合，而不是只写新增项：

# resetkeys 后同时声明所有仍应保留的键模式
redis-cli ACL SETUSER app resetkeys \
  '~tenant:42:*' \
  '~tenant:43:*' \
  '~shared:*'

# 变更命令权限不在本文范围；这里仅验证键模式快照
redis-cli ACL GETUSER app

用快照和试运行验证 ACL 变更

安全控制要留下可回滚的证据。变更前先记录 ACL GETUSER app 返回的键规则，把它和本次完整集合放入变更单；修改后再次读取快照，再针对代表性键运行 ACL DRYRUN。这样可以区分“规则没有写入”和“规则写入了但业务命令仍被拒绝”。

# 记录变更前规则，输出应进入受控变更日志
redis-cli ACL GETUSER app > acl-app-before.txt

# 只把完整集合写入 resetkeys，避免遗漏仍在使用的模式
redis-cli ACL SETUSER app resetkeys '~tenant:42:*' '~tenant:43:*' '~shared:*'

# 读取变更后规则，并对代表性键做权限试运行
redis-cli ACL GETUSER app
redis-cli ACL DRYRUN app GET tenant:42:demo

回滚时不要凭记忆补模式，直接把 acl-app-before.txt 中确认过的完整键集合恢复到 resetkeys 命令。对于租户隔离场景，至少记录新增、删除、责任人和生效窗口；这比单纯看到一次 “OK” 更能说明访问边界没有被意外扩大或缩小。

相关问题

resetkeys 会删除 Redis 中已有的键吗？

不会。它清空的是用户的键模式授权规则，不是数据库里的键；旧键仍可能存在，只是该用户不能再访问。

只想新增键模式，必须使用 resetkeys 吗？

不必须。增量授权可以直接追加模式；如果使用 resetkeys，就必须把旧模式和新模式一起写入。

ACL GETUSER 能证明业务请求一定成功吗？

不能。它能帮助确认规则快照，实际判断还要结合命令权限、目标键和 ACL DRYRUN 的结果。