大规模生产环境Redis脚本安全优化：ACL限制Lua执行权限

正确禁止使用 EVAL 和 EVALSHA 的具体方法，是在 ACL SETUSER 命令中明确写入小写、无空格、带有连字符的 -eval 和 -evalsha，同时务必移除 -@admin，并且补充 ~* 与 &*。经常有人问，用 lua-time-limit 0 是否可行？答案是不可靠——它只是触发超时中断，本质上不属于权限控制手段。配置完成后，一定要通过新连接执行 AUTH 实际操作验证，确认返回 NOPERM 错误，并且记得运行 CONFIG REWRITE 或 ACL SAVE 进行持久化，否则重启后规则就会丢失。

ACL SETUSER 命令中如何正确禁用 EVAL 和 EVALSHA

直接在 ACL SETUSER 中移除这两个命令时，不是添加 +eval，而是使用减号前缀。常见的踩坑点包括：遗漏连字符、写成大写 -EVALSHA（注意大小写敏感），或者误加空格变为 - eval——Redis 会静默忽略无效的权限项，导致实际并未生效。

正确的写法其实很简单：全部小写、无空格、连字符必须紧贴命令名。

ACL SETUSER limiteduser on nopass ~* &* -@admin -eval -evalsha

• -@admin 必须显式移除，否则该命令组隐含包含了 eval 和 evalsha。
• ~* 和 &* 是必需的补充，缺少的话用户连 key 读写以及 pub/sub 功能都会被锁死。
• 不要指望用 +@read +@write 来替代，这两个命令组本身就不包含 eval 相关指令，而且未来版本扩展后可能带来隐患；显式禁用是最可控的做法。

为什么 lua-time-limit 0 不是禁用 Lua 的可靠方式

lua-time-limit 0 在配置里看起来像是“关闭”，实际上只是将超时阈值设为 0 毫秒。效果是：脚本一启动就会触发超时中断，返回 (error) BUSYSCRIPT。这并非权限控制，而是运行时的暴力终止，而且无法区分合法的短脚本与恶意的长脚本——所有 Lua 调用都会失败，包括你自己编写的限流、原子计数等核心业务脚本。

真正需要的是权限隔离，而不是功能阉割：

• 采用 ACL 方式时，default 用户依然可以执行 Lua，运维和监控工具不受影响。
• 受限用户调用 EVAL 时直接返回 (error) NOPERM，错误语义清晰，客户端可以明确执行降级处理。
• lua-time-limit 只影响执行时长，对 SCRIPT LOAD、SCRIPT EXISTS 等元操作完全没有约束力。

ACL 配置后如何验证 EVAL 确实被拦截

不要只查看 ACL GETUSER 的输出，要真实切换用户并触发命令。关键点在于认证方式和错误响应必须匹配：

AUTH limiteduser ""
EVAL "return 'test'" 0

预期响应必须是：

(error) NOPERM this user has no permissions to run the 'eval' command

• 如果返回 (error) ERR unknown command `EVAL`，说明用户根本没有启用（on 缺失）或 ACL 规则未加载。
• 如果返回 (error) NOSCRIPT，说明脚本未预热，但命令本身可以执行——ACL 未生效。
• 务必使用新连接进行测试，旧连接还保留着认证前的权限上下文，测试结果不准确。

生产环境里最容易被忽略的 ACL 持久化问题

在线执行 ACL SETUSER 只存在于内存中。Redis 重启后规则全部丢失，用户自动回退到 default 的全权限状态——这是最危险的静默失效。

必须完成以下两件事之一：

• 执行 CONFIG REWRITE，让 Redis 把当前 ACL 写入 redis.conf 或其 aclfile 指定的路径。
• 手动编辑 aclfile（例如 /etc/redis/users.acl），写入类似 user limiteduser on nopass ~* &* -@admin -eval -evalsha 的内容，再使用 ACL LOAD 加载。

检查是否生效的方法：用 ACL LIST 查看输出，再确认 CONFIG GET aclfile 返回的路径存在且可读——很多团队配置了 aclfile 却忘记放置文件，或者权限设为了 root-only，导致加载时静默跳过。