如何保障Redis脚本在大规模生产环境下的安全性_通过ACL限制Lua脚本执行权限

<p>正确禁用EVAL和EVALSHA需在ACL SETUSER中显式使用小写无空格带连字符的-eval -evalsha，并移除-@admin、补充~ &；lua-time-limit 0不可靠，因其仅触发超时而非权限控制；配置后须用新连接AUTH实测返回NOPERM错误，并执行CONFIG REWRITE或ACL SAVE持久化。</p>

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 ""<br>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。