db.getUser()是查单个用户角色最直接方式,需先use到对应数据库,返回该库中显式授予的角色及authenticationRestrictions限制,但不显示跨库或继承权限。
它返回用户在当前数据库下被授予的所有角色,包括 role 和 db 字段,清楚标明“谁在哪个库被给了什么角色”。但必须先 use 到对应数据库——比如查 admin 库里的 root 用户,得先执行 use admin,再运行 db.getUser("root")。否则返回空或查到错误库的同名用户。
常见错误是连着 admin 库却没切库就执行 db.getUser("appuser"),结果查不到——因为该用户可能只在 myapp 库创建。返回结果里的 authenticationRestrictions 字段如果非空,说明这个用户还受 IP 或证书限制,不能只看角色就认为能连上。
它不展开权限细节,但能一眼看清当前数据库里有哪些人、各自担哪些角色。比如执行 use myapp 后运行 db.getUsers(),就能看到 appReader 用户是否被赋予了 read 角色,或者 appWriter 是否有 readWrite。
db.getUsers({showCredentials: true})——它会暴露密码哈希,生产环境严禁roles 数组只包含显式授予的角色,不体现继承关系(比如某角色内部又 roles 了另一个角色)userAdminAnyDatabase),这个命令不会显示,因为它只查当前库它比 db.getUser() 更底层,也更严格:必须显式指定 db 参数,且只返回该数据库上下文中的角色。例如:db.runCommand({ usersInfo: { user: "admin_user", db: "admin" } }) 才能查到 admin 库里定义的全局角色。
如果你在 test 库执行 usersInfo 查一个拥有 clusterAdmin 的用户,结果里根本不会出现这个角色——因为 clusterAdmin 只能在 admin 库中定义和查询。所以审计时务必确认目标用户是否在 admin 库被授予权限,不能只依赖当前连接库的结果。
db.getUser() 和 usersInfo 都只告诉你“有哪些角色”,但不告诉你这些角色到底允许做什么操作。比如 readWrite 看似明确,但它在不同数据库里生效范围可能不同;自定义角色还可能叠加 authenticationRestrictions 或限定到特定集合。
真正要看清权限边界,必须用 db.runCommand({ rolesInfo: { role: "xxx", db: "yyy" }, showPrivileges: true })。尤其注意:
readWriteAnyDatabase)必须查 admin 库,否则报 Role not found
rolesInfo 不自动递归展开,得手动查被引用角色showPrivileges: true 必须显式写,否则返回里 privileges 字段为空权限最终是否生效,还取决于连接时的 --authenticationDatabase、实际网络来源是否匹配 authenticationRestrictions,以及有没有 localhost exception 等隐性规则——光看角色列表,永远只是半截真相。
Tplink企业版路由器WiFi名称的默认设置介绍(Tplink企业版路由器WiFi名称的默认设置是什么)
Tplink路由器灯常亮无法上网的原因分析(如何解决Tplink路由器灯常亮无法上网的问题)
Tplink千兆企业级路由器自动重启的作用和优势介绍(如何设置Tplink千兆企业级路由器自动重启功能)
一根天线的tplink路由器有哪些(一根天线的Tplink路由器的特点和优势介绍)
tplink路由器外网访问不了nas(Tplink路由器外网访问NAS的原因分析)
Tplink无法搜到路由器的原因分析(如何解决Tplink无法搜到路由器的问题)