MongoDB默认禁止访问system.*集合，因权限模型将其视为元数据敏感区，需显式授予viewUserManagement等特权方可操作，启用访问控制是前提。
默认情况下，MongoDB用户无法访问 system.* 集合 —— 但前提是启用了访问控制且角色权限未显式授予。 直接给用户分配 read 或 readWrite 等内置角色时，system.* 集合（如 system.users、system.roles）仍被自动排除在权限范围外。真正的问题在于：某些自定义角色或高权限角色（比如 userAdminAnyDatabase）可能间接允许读取这些集合，而用户误以为“只要没显式授权就能安全”。
为什么 system.* 集合默认不可见？
MongoDB 的权限模型把 system.* 集合视为元数据敏感区，即使你对某个数据库有 read 权限，db.getCollectionNames() 也不会列出 system.*，db.system.users.find() 也会直接报 "not authorized"。这不是靠隐藏实现的，而是内核级硬限制：所有对 system.* 的读写操作都需明确匹配对应特权（如 viewUserManagement、viewRoleManagement），普通 CRUD 动作一律拒绝。
常见错误现象：
- 用户执行
db.system.users.find()报错："not authorized on admin to execute command find" - 用
readWrite角色连接后，show collections不显示system.users，但用户误以为“是空的”，其实根本没权限看 - 在
admin库下创建自定义角色时，忘记移除system.*相关的privileges字段，导致该角色可绕过限制
如何确认用户真的不能访问 system.*？
别只信 show collections 的输出 —— 它本身就会过滤掉 system.*。真正验证方式是主动尝试读取：
- 切换到
admin库：use admin - 执行：
db.system.users.findOne()—— 如果返回not authorized，说明限制生效 - 再试：
db.runCommand({listCollections: 1, filter: {name: /^system\./}})—— 正常应返回空数组或权限错误，而非具体集合列表
注意：system.version 是例外，部分内置角色（如 clusterMonitor）允许读取它，但不构成安全风险；真正要盯住的是 system.users 和 system.roles。
哪些角色会意外放开 system.* 访问？
不是所有高权限角色都等价。以下角色自带对 system.* 的隐式或显式访问能力：
-
userAdminAnyDatabase：可读写admin.system.users和admin.system.roles -
dbAdminAnyDatabase：可读system.*（包括system.indexes等），但不包括system.users - 自定义角色中若包含
privileges字段，且resource指向{db: "admin", collection: "system.users"}，则直接突破限制
性能影响几乎为零 —— 这类检查发生在授权阶段，不涉及磁盘 I/O。但兼容性要注意：MongoDB 4.0+ 开始强制要求角色定义中显式声明 system.* 资源才能访问，旧版（如 3.6）可能因配置宽松导致误放行。
最稳妥的限制方式：不用动，但得懂边界
你不需要额外配置来“禁止访问 system.*”，MongoDB 默认就做了。真正要做的只有两件事：
- 确保启动时启用访问控制（
--auth或security.authorization: enabled），否则所有限制形同虚设 - 给业务用户分配最小必要角色，避开
userAdminAnyDatabase、root等全库管理角色；哪怕只是查数据，也优先用{role: "read", db: "myapp"}而非readAnyDatabase
容易被忽略的点：system.* 的保护只针对客户端命令，不防 mongodump/mongorestore —— 如果备份工具用的是管理员账号，导出文件里依然含 system.users 数据。所以权限控制必须配合运维流程，不能只靠数据库层。
