Doris用户管理

用户管理是Doris权限体系的核心，所有用户操作均依赖于严格的权限控制。本文将用户管理操作与对应权限要求深度绑定，详细说明用户创建、修改、删除等全流程的权限边界及操作规范。

一、用户标识与权限基础

用户标识（User Identity）

• 唯一标识格式：username@'userhost'，其中：
  • username：用户名称（大小写敏感）
  • userhost：登录IP限制（支持%通配符，如192.168.%）
• 示例：dev@'192.168.%'表示允许从192.168网段登录的dev用户

核心权限关联

用户管理操作依赖以下关键权限（需重点关注）：

• Admin_priv：最高级权限，涵盖所有操作
• Grant_priv：权限管理权限（含用户创建/删除），支持层级控制
• Node_priv：节点管理权限（仅root默认拥有，与用户管理间接相关）

二、用户创建：权限要求与操作规范

创建用户语法

CREATE USER [IF NOT EXISTS] user_identity [IDENTIFIED BY 'password']

所需权限

操作执行者	所需权限条件
管理员用户	具备Admin_priv
普通授权用户	具备GLOBAL层级Grant_priv 或 DATABASE层级Grant_priv

操作示例

-- 1. 管理员（root）创建用户（无权限限制）
CREATE USER bi_user@'10.0.%' IDENTIFIED BY 'Bi@2024';

-- 2. 仅具备DATABASE层级Grant_priv的用户
-- 只能创建访问该数据库的用户（需显式指定数据库权限范围）
CREATE USER db_user@'%' IDENTIFIED BY 'Db@369';
GRANT Select_priv ON test_db.* TO db_user@'%'; -- 必须同步授权

关键限制

• 无Grant_priv的用户无法创建其他用户
• 仅GLOBAL层级Grant_priv用户可创建userhost='%'（任意IP登录）的用户
• 密码强度受validate_password_policy控制（见前文密码管理部分）

三、用户删除：权限边界与操作步骤

删除用户语法

DROP USER [IF EXISTS] user_identity

所需权限

操作执行者	所需权限条件
管理员用户	具备Admin_priv
普通授权用户	必须具备GLOBAL层级Grant_priv

操作示例

-- 删除指定用户（带防误删检查）
DROP USER IF EXISTS bi_user@'10.0.%';

连锁影响

• 删除用户后，其关联的默认角色自动删除
• 该用户授予的权限需手动回收（不会自动撤销）
• 正在执行的会话不会立即中断，下次登录失效

四、密码管理：不同角色的操作权限

1. 修改他人密码

语法

SET PASSWORD FOR user_identity = PASSWORD('new_password')

所需权限

操作执行者	所需权限条件
管理员用户	具备Admin_priv
普通授权用户	具备GLOBAL层级Grant_priv 或 对应数据库的Grant_priv

2. 修改自身密码

语法

SET PASSWORD = PASSWORD('new_password')

权限要求

• 无需额外权限，仅需验证当前密码（通过CURRENT_USER()确认身份）
• 示例：

  SELECT CURRENT_USER(); -- 确认身份：db_user@'%'
  SET PASSWORD = PASSWORD('NewDb@789');
  

3. 密码重置特殊场景

• root用户密码重置：仅root可自行修改，其他用户无权限
• 批量密码更新：需具备GLOBAL层级Grant_priv，通过脚本批量执行SET PASSWORD

五、用户授权：权限赋予与回收的权限要求

授予权限（GRANT）

语法

GRANT privilege_list ON level_spec TO user_identity/role_name

所需权限

• 需具备对应层级的Grant_priv + 被授予的权限本身
• 示例：授予test_db的Select_priv需同时具备：
  • test_db的Grant_priv
  • test_db的Select_priv

回收权限（REVOKE）

语法

REVOKE privilege_list ON level_spec FROM user_identity/role_name

所需权限

• 与授予该权限时的要求一致（需对应层级的Grant_priv）
• 无法回收自身不具备的权限

六、用户-角色关联操作的权限控制

1. 为用户分配角色

GRANT role_name TO user_identity

• 所需权限：具备GLOBAL层级Grant_priv 或 角色所属层级的Grant_priv

2. 从用户撤销角色

REVOKE role_name FROM user_identity

• 所需权限：与分配角色时的权限要求一致

七、用户管理权限对照表

操作类型	所需最小权限	适用范围
创建用户	DATABASE层级Grant_priv	仅能创建访问该数据库的用户
创建任意用户	GLOBAL层级Grant_priv	所有IP范围的用户
删除用户	GLOBAL层级Grant_priv	所有用户
修改他人密码	GLOBAL层级Grant_priv	所有用户
修改自身密码	无（需验证当前身份）	仅自身
为用户分配角色	GLOBAL层级Grant_priv	所有角色
设置用户属性	GLOBAL层级Grant_priv	所有用户

八、典型场景权限配置示例

场景1：创建数据库管理员

-- 1. 创建用户（需GLOBAL Grant_priv）
CREATE USER db_admin@'192.168.%' IDENTIFIED BY 'Admin@123';

-- 2. 授予数据库级管理权限
GRANT Create_priv, Alter_priv, Drop_priv, Grant_priv ON test_db.* TO db_admin@'192.168.%';

场景2：创建只读用户

-- 1. 创建用户（数据库管理员即可操作）
CREATE USER read_user@'%' IDENTIFIED BY 'Read@456';

-- 2. 授予只读权限
GRANT Select_priv ON test_db.* TO read_user@'%';

场景3：限制用户登录IP

-- 允许10.0.0网段登录，拒绝其他IP
CREATE USER app_user@'10.0.%' IDENTIFIED BY 'App@789';

-- 高优先级禁止特定IP（即使属于10.0网段）
CREATE USER app_user@'10.0.0.100' IDENTIFIED BY 'invalid'; -- 密码无效化

通过明确用户管理各环节的权限要求，可避免越权操作风险。实际配置时建议遵循“最小权限原则”，结合角色批量管理权限，减少重复操作。所有操作需通过SHOW GRANTS FOR user_identity;验证权限是否正确生效。