正确禁用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 输出，要真实切换用户并触发命令。关键点在于认证方式和错误响应必须匹配：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
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。
