MongoDB权限不存于system.roles集合，它只存角色定义；查用户具体Action需组合usersInfo与rolesInfo逐层展开，并注意认证库和IP限制。
直接说结论： MongoDB 的权限不存于 system.roles 集合里，查这个集合根本看不到“谁有哪个 Action”，它只存角色定义（role + privileges），不记录用户与 Action 的映射关系。真要查“哪些用户拥有某个 Action”，必须从用户→角色→privileges 逐层展开，不能跳步。
db.getUser() 和 db.getUsers() 不会显示 Action，只列角色名
执行 db.getUser("alice") 或 db.getUsers() 返回的 roles 字段类似这样：
{ "role": "readWrite", "db": "orders" }
它完全不告诉你 readWrite 允许哪些具体操作（如 find、insert），更不会列出该用户实际能执行的所有 Action。这是常见误判起点——把“角色名”当成“权限清单”。
- 必须先
use到用户创建所在的数据库（比如用户在admin库创建，就得use admin后再查） - 返回空数组？大概率是库没切对，不是用户不存在
-
authenticationRestrictions字段若存在，说明该用户被 IP 或证书限制，Action 即便合法也可能被拦截
查 Action 必须用 rolesInfo 或 getRole()，且需指定 db
内置角色（如 readWrite、dbAdmin）的权限动作，只能通过 rolesInfo 命令展开。例如想确认 readWrite 是否包含 dropCollection：
use admin
db.runCommand({rolesInfo: {role: "readWrite", db: "admin"}, showPrivileges: true})
注意两点：
- 必须显式传
{role: "...", db: "..."}，不能只传字符串"readWrite"，否则在非admin库执行会报Role not found -
showPrivileges: true是关键，否则返回内容里没有privileges数组，也就看不到actions列表 - 自定义角色可能通过
roles字段继承其他角色，需递归调用rolesInfo查清全部来源
system.roles 集合只存角色定义，不反映用户实际权限
system.roles 是系统集合，存放的是角色元数据（名称、privileges、inheritedRoles 等），但：
- 它不记录任何用户信息，查不到“谁被授了这个角色”
- 它不处理权限叠加逻辑：用户有多个角色时，最终生效的 Action 是各角色 privileges 的并集，而
system.roles只静态存单个角色定义 - 它不体现
authenticationRestrictions或--authenticationDatabase配置的影响——这两项能让一个“理论上拥有 Action”的用户实际无法执行
所以直接 db.system.roles.find() 对定位“哪些用户能执行某 Action”毫无帮助，纯属白费力气。
真正能关联用户和 Action 的唯一路径是 usersInfo + rolesInfo 组合
如果非要回答“哪些用户有 find 权限”，唯一可行链路是：
- 先用
db.getUsers()拿到所有用户及其roles - 对每个角色，调用
rolesInfo查出它包含哪些actions（注意跨库问题） - 手动比对每个用户的
roles中是否含至少一个带"find"的角色 - 再检查该用户
authenticationRestrictions是否允许当前连接 IP - 最后确认连接时用的
--authenticationDatabase是否匹配用户所在库
没有命令能一键输出“用户→Action”映射表。最容易被忽略的是最后一环：用户明明在 admin 库配了 root，但服务启动加了 --authenticationDatabase myapp，那登录时就必须用 myapp 库的凭证，否则连认证都过不去，更别说 Action 了。
