引言

完成数据库，表，索引这些核心对象的运作之后，“用户与权限控制”就成了保障 KingbaseES 数据安全的重点所在，经由细致的用户运作和权限分配，可以规避未授权访问以及误操作之类的风险，比如普通用户就无权删除核心表。本文针对“ksql 命令行操作用户与权限”展开论述，覆盖从“创建用户 - 查看用户 - 修改用户 - 授权/回收权限 - 删除用户”这样完整的流程，并结合真实的业务场景来分解具体的执行步骤，各个阶段均给出相关的语法，例子以及防止常见错误的提示，从而保证初学者能够掌握到安全控制的主要要点。

一、前置准备：明确 “谁来操作” 与 “操作基础”

用户与权限运作属于“高危运作”，要保证运作环境具备如下条件（结合前面内容，防止因为权限不够或者环境有误致使运作出现故障）

1.1 1. 用管理员账号连接数据库

管理员用户（比如预设的system）具备创建，更改，删除其他用户的相关权限，普通用户并不具有这些权限，要经由 ksql 以管理员的身份去关联本地数据库

# 连接默认数据库 kingbase，用户为 systemksql -d kingbase -U system

连接创建之后，提示符变为kingbase=#，其中，管理员的提示符是#，普通用户的是>，经由提示符能够立即识别出权限等级

1.2 2. 确认操作依赖的对象（衔接前文）

后续权限示例将基于前文创建的对象：

• 数据库：kingbase（默认数据库）、test（前文创建的测试库）；
• 模式：test_schema（前文创建的模式）；
• 表：test_schema.sys_user（前文创建的用户表）；
  确保这些对象存在（可通过\l查数据库、\dn查模式、\dt test_schema.*查表），若不存在可参考前文重新创建，避免示例执行失败。
  

二、核心概念：用户与权限的 “层级关系”

新手要先领会 KingbaseES 权限的“层级特性”，即权限按“数据库 → 模式 → 表”由高到低分级，只有得到上层权限才可操作下层对象（若无数据库关联权限，则无法操作库中的表）。
KingbaseES隐含的权限层级如下：

KingbaseES存在隐含的权限层级，后面的全部权限操作都会环绕这三个层级来执行，以此保证权限分配达到“最小化”效果（也就是仅仅给予用户所需的权限，防止出现过度授权的情况）。

三、创建用户：基础用户管理第一步

创建用户属于权限管理的起始部分，要给出用户名，密码以及一些基本属性，比如默认数据库，密码有效期限等，接下来会阐述CREATE USER的关键语法，并且依照安全方面的良好做法来给出例子

3.1 1. 基础语法

CREATEUSER用户名WITHPASSWORD'密码'[选项];

下面这些“选项”的解释（适合初学者了解）：

• PASSWORD '密码'：用户登录密码（建议包含大小写、数字、特殊字符，避免弱密码）；
• DEFAULT DATABASE 数据库名指的是用户登录时默认关联的数据库，比如kingbase。
• DEFAULT SCHEMA是指用户默认会用的模式，比如test_schema。
• CREATEDB：允许用户创建数据库（前文提到的建库权限，仅管理员可授予）；
• INHERIT：用户自动继承所属角色的权限（默认开启，无需手动指定）。

3.2 2. 实操示例：创建普通用户

示例 ：创建基础用户test（仅用于访问数据，无建库权限）

CREATEUSERtestWITHPASSWORD'123456'

• 成功验证：执行后提示CREATE ROLE（KingbaseES 中 “用户” 本质是特殊角色，故返回CREATE ROLE），表示用户创建成功。

3.3 3. 注意事项（安全必看）

1. 密码复杂度：生产环境需设置强密码（如至少 8 位，含大小写、数字、特殊字符），避免123456等弱密码；
2. 避免重复创建：若用户名已存在，执行CREATE USER会报错 “role already exists”，需先删除旧用户或改用ALTER USER修改。

四、查看用户：了解用户权限与属性

创建好用户之后，要利用 ksql 命令来查看用户的详细信息，包含权限，默认属性以及所属角色等方面的内容，建议采用\du这一系列的命令，这属于一种最为直观的查看用户信息的方式。

4.1 1. 查看所有用户（\du 命令）

执行\du可列出当前数据库中所有用户的核心信息，快速了解用户列表：

\du

执行结果示例（关键信息筛选）：

4.2 2. 查看单个用户详情（\du 用户名）

若需查看某一用户的详细权限（如test），执行\du 用户名：

\du test

执行结果示例：

4.3 3. 查看用户的权限明细（\dp 命令）

若需更精细地查看用户对某类对象（如表、模式）的权限，可使用\dp命令：

• 查看表权限：\dp 表名（如查看sys_user表的权限）；

  \dp test_schema.sys_user

五、修改用户：适配用户属性变更

业务需求发生改变的时候，要对用户属性做一些调整，比如重置密码或者增减创建数据库的权限，ALTER USER这个核心语法包含一些常见的操作

5.1 1. 修改用户密码（最常用操作）

当用户忘了密码或者是到了规定的时间得要换密码时，管理员可以运行如下命令（拿test来举例）：

-- 语法：ALTER USER 用户名 WITH PASSWORD '新密码';ALTERUSERtestWITHPASSWORD'User1@New2024';

• 验证：修改之后，用户就能重新登录（用ksql -d kingbase -U user1命令），然后输入新的密码来验证是否有效

5.2 2. 授予用户属性（如建库权限）

如果想要给test授予创建数据库的权限（之前没有这个权限）

-- 语法：ALTER USER 用户名 权限属性;ALTERUSERtest CREATEDB;

• 验证：执行\du test这条命令，在Attributes栏里能看到创建 DB这个选项，这就表明权限已经被添加了

5.3 3. 撤销用户属性（如收回建库权限）

若test不再需要建库权限，可收回：

-- 语法：ALTER USER 用户名 NO 权限属性;ALTERUSERtest NOCREATEDB;

• 验证：执行\du test，Attributes中的Create DB会消失。

5.4 4. 修改用户默认属性（如默认数据库）

将user1的默认数据库从kingbase改为test（需确保test_db已存在）：

ALTERUSERtestSETDEFAULTDATABASEtest;

• 验证：等用户test下次登录的时候，只要用ksql -U user1这个命令，系统就会自动帮它连接到test这个数据库，不需要手动加上-d test这样的参数。

六、权限控制：授予与回收（核心环节）

权限控制处于用户运作的核心地位，要依照“数据库→模式→表”这样的层级来执行权限的赋予或者收回，从而保证用户只能对自身业务范畴之内的对象实施操作，有关GRANT（即赋予）和REVOKE（即收回）的语法，下面将针对不同情形展开详细阐述

6.1 1. 授予权限（GRANT 命令）

场景 1：授予数据库连接权限（用户需先能连接库，才能操作内部对象）

向test赋予连接kingbase数据库的权限

-- 语法：GRANT 权限类型 ON DATABASE 数据库名 TO 用户名;GRANTCONNECTONDATABASEkingbaseTOtest;

• 作用：如果没有这项权限，那么test就无法与kingbase数据库建立联系，系统将会显示错误信息“permission denied to connect to database kingbase”。
  

场景 2：授予模式访问权限（用户需能访问模式，才能操作模式下的表）

给test授予访问test_schema模式的权限：

-- 语法：GRANT 权限类型 ON SCHEMA 模式名 TO 用户名;GRANTUSAGEONSCHEMAtest_schemaTOtest;

• 作用：USAGE权限是访问模式的基础，无此权限，test无法查看test_schema下的表。

场景 3：授予表操作权限（用户业务核心权限，如查询、插入）

给test授予test_schema.sys_user表的SELECT（查询）和INSERT（插入）权限：

-- 语法：GRANT 权限类型 ON 表名 TO 用户名;GRANTSELECT,INSERTONtest_schema.sys_userTOtest;

• 进阶：授予所有权限（谨慎！生产环境不推荐）：

  GRANTALLPRIVILEGESONtest_schema.sys_userTOtest;

• 验证：执行\dp test_schema.sys_user，可看到test拥有的权限。
  

6.2 2. 回收权限（REVOKE 命令）

当用户不再需要某类权限时（如test无需插入数据），需及时回收，避免数据风险：

场景：回收test对sys_user表的INSERT权限

-- 语法：REVOKE 权限类型 ON 表名 FROM 用户名;REVOKEINSERTONtest_schema.sys_userFROMtest;

• 验证：执行\dp test_schema.sys_user，test的权限会只剩SELECT；
• 注意：回收权限需管理员执行，且只能回收之前授予的权限（无法回收用户默认拥有的权限）。

七、删除用户：高危操作，谨慎执行

用户被移除时，其本人及其相关权限将会被彻底移除，但是所创建的对象（诸如表，视图等）不会遭到删除，而在执行此类操作之前，一定要确保该用户与核心业务没有联系，其具体的执行步骤包含如下几点：

7.1 1. 基础语法（加 IF EXISTS 避免报错）

DROPUSERIFEXISTS用户名;

• IF EXISTS：若用户不存在，仅提示警告（NOTICE: role "用户名" does not exist, skipping），不报错，避免中断后续操作。

7.2 2. 特殊场景：用户有创建的对象（需 CASCADE）

用户test已创建表，比如test_schema.user2_table，如果直接删除，会出现错误提示：“role ‘test’ 无法被删除，因为存在对象依賴于此角色”，此时应当加上CASCADE参数执行级联删除以解决依赖问题（不过这只会删除与该用户相关的权限，并不会删除由该用户创建的各类对象）。

-- 语法：DROP USER IF EXISTS 用户名 CASCADE;DROPUSERIFEXISTStestCASCADE;

• 高危提醒：CASCADE 用来处理“用户存在依赖对象”的删除情况，并不会删除由用户创建的表/视图，用户得自行执行 DROP 操作来删除自身创建的对象（例如：DROP TABLE test_schema.user2_table;）。

7.3 3. 删除前的确认步骤（必做）

1. 确认用户无活跃会话：执行SELECT pid, usename FROM pg_stat_activity WHERE usename = 'user1';，若有结果，先终止会话（SELECT pg_terminate_backend(pid);）；
2. 确认用户无核心权限：执行\du user1，确认用户无Superuser等关键权限；
3. 确认用户无业务对象：执行SELECT tablename FROM pg_tables WHERE tableowner = 'user1';，确认用户无创建的表。

八、常见问题排查：新手常踩的权限坑

问题 1：用户登录报错 “连接数据库的权限被拒绝”

报错信息：

ERROR: permission denied to connect to database "kingbase"

原因：用户无该数据库的CONNECT权限（如user1未被授予连接kingbase的权限）。
解决方案：管理员授予CONNECT权限：

GRANTCONNECTONDATABASEkingbaseTOuser1;

问题 2：用户查询表报错 “对模式的权限被拒绝”

报错信息：

ERROR: permission denied for schema test_schema

原因：用户无该模式的USAGE权限，无法访问模式下的表。
解决方案：授予模式访问权限：

GRANTUSAGEONSCHEMAtest_schemaTOuser1;

问题 3：删除用户报错 “存在依赖它的对象”

报错信息：

ERROR: role "user1" cannot be dropped because some objects depend on it

原因：用户有创建的对象（如表、视图）或被授予了其他对象的权限。
解决方案：加CASCADE级联删除依赖：

DROPUSERIFEXISTSuser1CASCADE;

• 后续需手动删除用户创建的对象（如DROP TABLE test_schema.user1_table;）。

九、总结：用户权限管理的核心原则

本文完整覆盖了用户 “创建→查看→修改→权限→删除” 的全流程，核心原则可总结为：

1. 最小权限原则：只赋予用户必要权限，比如普通用户只需表的SELECT权限，不必授予DROP权限。
2. 权限层级清晰：按照“数据库→模式→表”的顺序逐层授予权限，不能越级授权（即如果没有模式权限，却直接赋予表权限）。
3. 定期审计：定期执行审计操作，利用\du和\dp命令定时检查用户权限，并及时收回多余权限，防止出现权限泄露情况
4. 高危操作谨慎：删除用户前需确认会话、对象、权限，避免误删导致业务中断

掌握了用户与权限运作之后，你就具有了 KingbaseES 数据库安全控制的能力，下一篇文章我们会学习“事务运作”，从而保证多操作情况下数据的一致性（就像转账业务里的“扣款”和“入账”必须一起完成或者一起不完成一样）