readAnyDatabase角色在生产环境基本不能用，因其默认绕过库级隔离、隐式读取system.*集合暴露账号结构、4.0+起不再覆盖local/config库导致权限盲区，且与backup角色混用会触发mongo-connector同步失败。
readAnyDatabase 角色在生产环境基本不能用——它默认绕过库级隔离，且从 4.0 起不再覆盖 local 和 config 库，反而制造权限盲区。
为什么 readAnyDatabase 会绕过库级隔离
这个角色只在 admin 数据库中定义，但授权后用户能对所有非系统数据库执行 find、listCollections 等读操作，且 use otherdb 切库后无需二次鉴权。更关键的是：它隐式包含对 system.* 集合的读权限（比如 system.users），等于间接暴露账号结构。
- 只要认证成功，就能执行
use admin; db.system.users.find()查到所有用户明文角色配置 - 配合
listDatabases（默认开启），可枚举全部库名，为后续渗透提供地图 - 如果误配了
readWriteAnyDatabase或混用root，风险直接升级为删库
4.0+ 版本下 local/config 库读权限失效
官方明确移除了 readAnyDatabase 对 local 和 config 库的访问能力——这不是 bug，是安全收敛。但很多运维没意识到这点，导致监控脚本或 mongo-connector 同步失败，然后错误地给用户额外加 {role:"read", db:"local"}，反而扩大了攻击面。
-
local.oplog.rs包含复制集全部变更日志，暴露业务写入模式 -
config.shards和config.databases暴露分片拓扑，便于定向攻击 - 单独授予
local权限时，必须限定仅需的集合（如只读local.replset），而非整个库
和 backup 角色混用会触发同步失败
当用户同时拥有 backup 和 readAnyDatabase，MongoDB 3.x+ 会拒绝 mongo-connector 的 oplog tailing 请求，报错 not authorized on local to execute command { collStats: "oplog.rs" }。这不是权限不足，而是角色冲突导致鉴权逻辑跳过 local 库校验。
- 根本原因：两个角色的权限集合并后，系统无法确定该以哪个 scope 执行
collStats - 典型现象：连接串带
?authSource=admin能连上，但同步卡在初始化阶段 - 解法不是加权限，而是拆分角色——用
backup单独做备份，另建专用账号跑mongo-connector
真正危险的从来不是权限本身，而是把 readAnyDatabase 当成“只读就安全”的心理暗示。它暴露的不只是数据，还有数据库的骨架结构。最小权限原则在这里不是建议，是止损底线。
