KingbaseES 金仓数据库：ksql 用户与权限管理实战

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

CREATE USER test WITH PASSWORD '123456';

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

3.3 注意事项（安全必看）

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

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

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

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

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

\du

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

（此处省略图片展示）

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

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

\du test

执行结果示例：

（此处省略图片展示）

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

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

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

\dp test_schema.sys_user

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ALTER USER test SET DEFAULT DATABASE test;

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

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

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

6.1 授予权限（GRANT 命令）

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

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

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

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

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

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

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

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

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

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

-- 语法：GRANT 权限类型 ON 表名 TO 用户名;
GRANT SELECT, INSERT ON test_schema.sys_user TO test;

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

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

GRANT ALL PRIVILEGES ON test_schema.sys_user TO test;

6.2 回收权限（REVOKE 命令）

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

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

-- 语法：REVOKE 权限类型 ON 表名 FROM 用户名;
REVOKE INSERT ON test_schema.sys_user FROM test;

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

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

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

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

DROP USER IF EXISTS 用户名;

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

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

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

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

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

7.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 权限：

GRANT CONNECT ON DATABASE kingbase TO user1;

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

报错信息：

ERROR: permission denied for schema test_schema

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

GRANT USAGE ON SCHEMA test_schema TO user1;

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

报错信息：

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

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

DROP USER IF EXISTS user1 CASCADE;

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

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

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

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

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